locked
Localization of Exception-messages is harmful RRS feed

  • Question

  • FxCop 1.35 rule Microsoft.Globalization CA1303 "Do not pass literals as localized parameters." will, among other things, report problems with the 'message' string argument to all System.Exception-derived classes' constructors.

     

    This is, IMHO, just plain wrong. I've been developing software in Sweden for over 25 years - and the lesson that I've learned again, and again, is that all information that is intended to be administrator- or developer-visible, not user-visible, should always be in english. This includes all error messages that are not displayed to users, naming in code, actual code etc.

     

    One of the most frustrating experiences one can have as a system administrator running software is to have it spit out localized error messages. Why?

     

    In one word: Search.

     

    So you get this fine error message from your application, and you wonder what the reason for this can be?

     

    You fire up the search engine of your choice, and you copy and paste the message and hit 'Search'. But - no joy, as it happens you're the first Swede to get this message. So what do you do? You try to back-translate it to english! (Which is often possible, because apparently they don't employ Nobel-prize-class translators to these texts - they're often silly to the point of being downright misleading or incorrect...) After much trouble you may, or may not, find the solution to your trouble - when it could have been so easy...

     

    There are secondary arguments as well, but the main argument is to maximize the potential use of the message - for which localization is counter-productive.

     

    [ Another horror story of misdirected localization is when Microsoft in the 90's decided to localize the keywords in Visual Basic for Applications in Excel, Word and Access (true! They did!), making just about all available documentation and community resources worthless, not to mention existing skills in similar environments. ]

     

    Localization is intended to make applications easier and friendlier to use - not harder to maintain, manage and run.

     

    I'm aware that this can be worked around in a number of ways, but...

     

    I do not like to start static code analysis with a number of exceptions to the rules - it's all too easy to continue down that path.

     

    Can we pretty please, with sugar on top, change this in upcoming releases of FxCop to the reverse?

     

    System.Exception messages should NOT be localized!

     

    (Even a completely cryptic exception message in finnish for a finnish app is better than localizing it. The point is that such messages should be unique for the circumstance - NOT changing depending on server or PC locale.)

    Monday, August 20, 2007 7:41 AM

Answers

  • There's many warnings that if "corrected" incorrectly actually result in worse code.  And there's more than one rule that doesn't make sense in many situations.  Yes, simply running Code Analysis and modifying code to get rid of warnings can lead to more serious problems that would not have existed without running Code Analysis.  But, the point is they all make sense in certain situations and you have to review the rules and define a "profile" of rules that make sense in your situation and project and provide guidance on how to resolve certain warnings.

    Wednesday, August 22, 2007 7:56 PM

All replies

  • The problem with exception message localization isn't so much whether they're localized or not, but rather the choice of culture that is used for exception messages at runtime.  I'm in perfect agreement that CurrentUICulture is generally a horrible choice for exception message localization.  However, I do still store exception messages in resource files (and occasionally even provide non-English translations ), even though I don't use CurrentUICulture as the default culture for exception message localization at runtime.

     

    Personally, I would much rather the rule not change since I do want to ensure that exception messages are read from resource files, if only to ensure that a non-English translation set can rapidly be provided should a client ever express a preference for reading their logged exception messages in another language.  However, I would be very happy to see a rule that flags cases where CurrentUICulture is used to localize exception messages...

    Tuesday, August 21, 2007 12:00 PM
  • Hello,

     

    The reason I'd like to see the rule changed is precisely because the messages should under normal circumstances NOT be translated at all (even worse if it's based on CurrentUICulture - CurrentCulture is bad enough...).

     

    Although I certainly can relate to the maxim that the customer is always right, and that there may be customers that despite advice to the contrary want exception messages, log messages, variable names and even code comments in the local language - I do not want to have this as the default behavior in a tool that is industry-wide in it's use.

     

    Not having the rule there as a default won't stop you from localizing your messages if your customers demand it - having it there does stop me from not-localizing (or at least preparing for it) which I consider to be directly harmful to the application.

     

    Another related reason is of course that logging and exception handling is so important that the threshold shoud be kept as low as possible, and it's still quite a bit more complicated to relocated the messages out to a resource file. This is secondary of course, and could be solved by better tools.

     

    The important message from my real world experience is that I believe the idea of localization of logs and exceptions come not from non-english speaker market demands, but from well meaning but misdirected efforts of english-speaking architects who do not have personal experience in trying to track down a problem in Windows Server 2003 that is only identified by an exception message translated into completely wacky swedish. I have. It's no joy.

     

    To summarize: Messages that are only intended for system developers and application maintainers and only for exceptional circumstances should not be translated at all, they should always be in english. Even bad english is ok (can't get worse than the translations in Windows Server into swedish...)

     

    I still want the rule off the default list.

    Tuesday, August 21, 2007 1:20 PM
  • Keep in mind, these rules are based upon the creation and deployment of a class library.  A class library has different localization requirements than an application.  If you're selling a class library to English, Swedish, and French customers you'll want your exceptions to display in their respective languages.

     

    Yes, an application need not localize exception messages because target audience of those exceptions is the developer.  But, as a developer it would be nice to get exception messages from a 3rd party library in their language, not the language of the 3rd party library's developer.

     

    When running FxCop/Code Analysis on applications and class libraries you're likely going to have different profiles for each.  In your application profile you'll very well disable this rule.

    Tuesday, August 21, 2007 8:29 PM
  • Thanks for your reply!

     

     Peter Ritchie wrote:

    If you're selling a class library to English, Swedish, and French customers you'll want your exceptions to display in their respective languages.

    No - that's just the point! We do not want that. Not at all. That's an incorrect assumption. It is _not_ helpful. I work in a typical non-English-native-speaking country and I've _never_ met a professional that think messages of this nature should be translated. It just complicates things.

     Peter Ritchie wrote:

    Yes, an application need not localize exception messages because target audience of those exceptions is the developer.  But, as a developer it would be nice to get exception messages from a 3rd party library in their language, not the language of the 3rd party library's developer.

    No, no, no. You've got it all wrong! In fact, the local Swedish computer magazines regularily print bloopers from the Microsoft Windows messages that are so garbled that the actual message is very much lost in translation. The only thing that sometimes saves us and lets us do our jobs is when error codes or other non-changing, non-localized information is made part of the translated message.

     

    Google is our friend. But not when messages are localized.

     Peter Ritchie wrote:

    When running FxCop/Code Analysis on applications and class libraries you're likely going to have different profiles for each.  In your application profile you'll very well disable this rule.

    Right, as I said I'm aware of several ways to get rid of the warning as such, but then we have the situation where I start disabling rule after rule because I feel like it. The default set should be so correct that there's rarely or ever a case where I'd like to disable it.

     

    It used to be that we were frustrated in Europe because US software was not adapted to our needs, such as not being able to display and print our funny characters, or not being able to print on anything but 8" paper (we don't even have inch-measured paper - we use mm...).

     

    Now we're frustrated because the pendulum has swung too much to the other end. Oh - so you don't speak English - we'll translate _everything_! Including language reserved words and uncaught exception messages and internal logs - which in turn messes up and complicates message log parsing etc etc ad nauseum...

     

    Have you tried parsing log messages that have localized the time stamp...? Have you ever seen a software log that will contain meta-data to define which culture was used to localize times, amounts, values etc? The localization problem of internal messages is much worse than just texts in fact.

     

    Please - you'll be saving both yourself and your customers lots of money with less texts that require translation as well as easier implementation - and at the same time you'll increase the usability of the software and libraries for the intended target group of these messages!

     

    Do bring this up again in your internal reviews for the next release, and verify that your assumptions about this really are correct. It is my considered opionon that they're not for the global markets. I know they are not for most of the western european market.

    Tuesday, August 21, 2007 9:25 PM
  •  Svante wrote:

    No - that's just the point! We do not want that. Not at all. That's an incorrect assumption. It is _not_ helpful. I work in a typical non-English-native-speaking country and I've _never_ met a professional that think messages of this nature should be translated. It just complicates things.

    My experience has been different, I'm routinely requested to display translated exception text.  The point is, every circumstance is different, you *need* to decide what rules are applicable and disable the rest; that's the way Code Analysis and FxCop work.  The Code Analysis developers cannot decide for you which rules are applicable and which are not for your circumstances, so they are all defaulted to enabled.

     Svante wrote:
    No, no, no. You've got it all wrong! In fact, the local Swedish computer magazines regularily print bloopers from the Microsoft Windows messages that are so garbled that the actual message is very much lost in translation. The only thing that sometimes saves us and lets us do our jobs is when error codes or other non-changing, non-localized information is made part of the translated message.

    That's a translation issue and has nothing to do with code analysis.  English-speaking people often poorly word English text, it's not unique to translation.

     Svante wrote:
    Right, as I said I'm aware of several ways to get rid of the warning as such, but then we have the situation where I start disabling rule after rule because I feel like it. The default set should be so correct that there's rarely or ever a case where I'd like to disable it.

    As I said, there's various scenarios that code analysis can be used in, the code analysis developers have no idea of what a particular customer's scenario is going to be (and it won't even be consistent from project to project) so the only thing they can do is enable all rules.  (I suppose it could go the other way, disable all rules and let the user enable the ones they need; but, I don't like that idea).  There's no way they can deliver something off-the-shelf that is perfect for ever user.  The way it is supposed to work is you evaluate the rules and decide which are applicable and which are not, disabling the ones that are not applicable to your scenario.

     Svante wrote:

    It used to be that we were frustrated in Europe because US software was not adapted to our needs, such as not being able to display and print our funny characters, or not being able to print on anything but 8" paper (we don't even have inch-measured paper - we use mm...).

     

    Now we're frustrated because the pendulum has swung too much to the other end. Oh - so you don't speak English - we'll translate _everything_! Including language reserved words and uncaught exception messages and internal logs - which in turn messes up and complicates message log parsing etc etc ad nauseum...

     

    Have you tried parsing log messages that have localized the time stamp...? Have you ever seen a software log that will contain meta-data to define which culture was used to localize times, amounts, values etc? The localization problem of internal messages is much worse than just texts in fact.

    Most of the above has nothing to do with code analysis; but yes, FxCop and Code Analysis have been less than configurable for an international market, and that's partially fixed in Orcas.

     Svante wrote:

    Please - you'll be saving both yourself and your customers lots of money with less texts that require translation as well as easier implementation - and at the same time you'll increase the usability of the software and libraries for the intended target group of these messages!

    In your opinion.  I still need to have translated exception messages, so I still need this warning.  If you don't need it, just disable it.

    Wednesday, August 22, 2007 3:29 PM
  • Thank you for the long and detailed response.

     

    We'll just have to agree to disagree on this point, and as you point out - I can disable the rule for my own software, but that was never the issue.

     

    What I've not been successful in communicating is that the rule in itself is harmful when enabled - i.e. when others, for instance Microsoft, guided by the rule translate exception texts. This makes Microsoft software harder to use for international developers and system administrators. Not easier. This rule is built on a faulty assumption.

     

    Anyway, I have yet another good subject for a future blog entry!

     

    Once again, thank you for the time taken in responding, even if the outcome is not as I was hoping for.

    Wednesday, August 22, 2007 7:45 PM
  • There's many warnings that if "corrected" incorrectly actually result in worse code.  And there's more than one rule that doesn't make sense in many situations.  Yes, simply running Code Analysis and modifying code to get rid of warnings can lead to more serious problems that would not have existed without running Code Analysis.  But, the point is they all make sense in certain situations and you have to review the rules and define a "profile" of rules that make sense in your situation and project and provide guidance on how to resolve certain warnings.

    Wednesday, August 22, 2007 7:56 PM
  • Hi,
    I just found this thread and I just want to say that I agree wholeheartedly with svante. The only time errors should be localized is when displayed to an end user (by an application). Framework / class library exceptions should be in english only. It's not true that localizing exception will help international programmers, quite the opposite in reality.
    (In my case it's french which is probably less problematic than swedish, but it's still a pain.)
    Regards,
    Charles
    Wednesday, September 12, 2007 2:12 AM
  • Do you really consider developers to be the only consumers of exception messages?  Even if this were the case, do you really believe that every developer on the planet is reasonably comfortable reading English?

     

    While I would agree without question that the .NET Framework designers made a horrible decision when they chose to tie exception message localization into the same culture used for localization strings meant to be displayed in an application UI, I would be equally uncomfortable with your proposed English-only approach.  Would you not be willing to consider an approach that allowed you to select the language of exception localization separately from the CurrentUICulture setting?

    Wednesday, September 12, 2007 5:55 PM
  • I can see value in having an alternative culture from the UI culture for use in exception text.  The problem lies in where that exception text is stored.  If it's stored in the resources you've got that inherent coupling of resource manager to UI culture that you'd have to circumvent.  This would have to be tied into the existing Exception class(es).

     

    I'm not sure what your experience with "globalization" is Nicole (I wouldn't be surprised if it's similar); but I often have to deal with a third type of culture "bilingual"; something the framework simply doesn't handle at the moment.  For example, right now I have customers that would demand the ability to have French exception text, some that will demand English exception text, and some that will demand bilingual exception text.  Which is contradictory to what Svante has suggested in that the CA rule to detect hard-coded exception text is "wrong".

     

    Wednesday, September 12, 2007 6:22 PM
  •  Peter Ritchie wrote:

    I can see value in having an alternative culture from the UI culture for use in exception text.  The problem lies in where that exception text is stored.  If it's stored in the resources you've got that inherent coupling of resource manager to UI culture that you'd have to circumvent.

     

    There's not really any unescapable coupling -- just a default use of CurrentUICulture if no culture is specified when using the ResourceManager.Get______ methods, which is trivial to work around.  For example, we've created our own resource code generators, one of which is meant for use with exception message resource files.  It uses an alternate source for the the default culture for localization of error messages, but also allows that default culture to be overridden.

     

     

     Peter Ritchie wrote:

    This would have to be tied into the existing Exception class(es).

     

    Yup.  Not exactly a trivial effort, but bad design decisions do tend to be costly to fix. 

     

     Peter Ritchie wrote:

    I'm not sure what your experience with "globalization" is Nicole (I wouldn't be surprised if it's similar); but I often have to deal with a third type of culture "bilingual"; something the framework simply doesn't handle at the moment.  For example, right now I have customers that would demand the ability to have French exception text, some that will demand English exception text, and some that will demand bilingual exception text.  Which is contradictory to what Svante has suggested in that the CA rule to detect hard-coded exception text is "wrong".

     

    What do you mean by "bilingual" in this context?  Localization of logged messages at read-time rather than write-time or merely a configurable choice of exception message localization at run-time?  I've done both, but demand for the former is quite rare, so most of my experience is with the latter.  What I have almost never seen is a client that is happy with exception messages being produced for administrator consumption in the language of choice of the end-user.

     

    A related issue that hasn't been mentioned in this thread is culture-specific formatting of values inserted into placeholder positions in exception messages.  This can be an even worse problem than the message language issue since an alternate culture may have been used for formatting even if the message wasn't localized due to the absence of an appropriate language resource.  For some examples of this sort of nonsense, see http://msmvps.com/blogs/calinoiu/archive/2006/06/30/103426.aspx.

    Wednesday, September 12, 2007 8:04 PM
  • I believe static code analysis should encode professional best practices - not customer requirements. Perhaps surprisingly - these are not always the same.

     

    In Sweden, and Finland, it's a frequent 'customer requirement' that code comments and code naming is in Swedish and Finnish respectively. I believe the same practice unfortunately is common in France and Germany. This is just simply not a good idea, and it never has been. The same argument applies to exception texts - which are always targeted at developers and system administrators. (Should they ever happen to become user-visible, it won't help to have them translated - they are still incomprehensible. They should just be identifiable.).

     

    When confronted with this type of 'customer requirement' I have always strongly argued in favor of using english for code and documentation (which includes logs and exceptions etc), and mostly the customer has respected my professional opinion in this case.

     

    If the official static analysis tool from Microsoft by default to the contrary requires texts to be localizable, my argument is considerably weakened, to the customers long-term detriment - in my professional opinion.

     

    As professionals we are required to do more than simply accept customer requirements. We are required to promote best practices - even in the face of initial customer views on the matter.

     

    It is my firm belief after 30 years of software development in the US, Europe and Asia, that English is the absolutely best practice we have for code, comments and documentation - when targeted to a developer audience. Operations manuals and such may from time to time require translation - but the original should be in English.

    Wednesday, September 12, 2007 8:21 PM
  •  Nicole Calinoiu wrote:
    A related issue that hasn't been mentioned in this thread is culture-specific formatting of values inserted into placeholder positions in exception messages.  This can be an even worse problem than the message language issue since an alternate culture may have been used for formatting even if the message wasn't localized due to the absence of an appropriate language resource.

     

    Thank you for pointing this important point again. I did mention it previously, but it got buried in too much text I guess. I wrote "Have you tried parsing log messages that have localized the time stamp...? Have you ever seen a software log that will contain meta-data to define which culture was used to localize times, amounts, values etc? The localization problem of internal messages is much worse than just texts in fact"

     

    Wednesday, September 12, 2007 8:27 PM
  • SvanteS, you can't see the possibly that someone may need to sell a single library to multiple developer customers with different cultures?

     

    Wednesday, September 12, 2007 8:28 PM
  •  Peter Ritchie wrote:
    SvanteS, you can't see the possibly that someone may need to sell a single library to multiple developer customers with different cultures?

     

     

    Certainly I do!

     

    Myself and my customers use Windows and the .NET Framework.

     

    I write such libraries for international market as well. The latest was for a leading content management system. All UI texts were translated into 13 languages, and the product as such supports extensive features for globalization and localization.

     

    All developer targeted texts are in english. Period. So is the code, comments and documentation. We even had some misspelled methods in the API for a time (GetChilds() instead of GetChildren() - but soo much better than HämtaBarnen() ;-). There might be a need for some translation of basic developer documentation for some markets, but I can't imagine that log messages will ever get translated.

     

    Your argument should apply equally well to naming and the library code, and the language itself - but you can't possibly mean that we should localize the library naming and the language keywords. Here's an example of what can happen then :-) !

     

    tomhet sammanhang_IdentifieraBegäran(objekt avsändare, HändelseArgument h)

    {

       HttpBegäran begäran = HttpBegäran.Nuvarande.Begäran;

       IHuvudman användare = HttpBegäran.Nuvarande.Begäran;

       om (användare == inget)

       {

           återvänd;

       }

      // Här avslutar vi övningen...

    }

     

    I think you'll recognize, just barely, the beginning of an event handler in a HttpModule.

     

    I'm sorry - the developer will have to know enough english to use the language reserved words and the framwork library - which actually is a pretty huge vocabulary, especially when namespaces, classes, methods, properties and parameters are so verbosely defined.

     

    We're living in a globalized world, where people, money, things and code travel the globe. Few, if any, companies will never have a situation where they'd like their code, or their codes' internal error messages, to be legible for non-native speakers. And then the best we have is english.

     

    The localization of exception texts is a mistake. Were it not - you'd have to argue for code as above.

     

    The scary thing is that VBA actually _is_ localized to the above extent, causing no end of grief on local markets...

     

    Svante

    Wednesday, September 12, 2007 8:51 PM
  •  Nicole Calinoiu wrote:

    What do you mean by "bilingual" in this context?  Localization of logged messages at read-time rather than write-time or merely a configurable choice of exception message localization at run-time?  I've done both, but demand for the former is quite rare, so most of my experience is with the latter.  What I have almost never seen is a client that is happy with exception messages being produced for administrator consumption in the language of choice of the end-user.

    I have customers that I need to support that requested messages retrieved at run-time contain message text in both "official" languages at the same time.  Which is in addition to customers who what messages in just French, and customers that want messages in just English.  The framework leaves a big hole in this case.  I can't use "Default" to denote bilingual because of it's explicit fall-back usage and I can't use "Invariant" for bilingual because of the side effect of that specific culture on parsing and formatting.

     

    Ideally, culture-pair support in the framework could solve this issue; but I don't see that happening.  In the meantime I need to support bilingual in other ways.  At this point, bilingual is French/English and English/French; but I wouldn't be surprised if other cultures require bilingual localization that doesn't involve both English or French.  I haven't researched the idea of creating a brand-new culture; but that' seems like a huge PITA with regard to deployment.

     

    On the topic of CA, having analysis detect when hard-coded text is used for exception text is a big plus for my teams to avoid having a service call for a customer who expects exception text in a specific language only to be presented with another.

    Wednesday, September 12, 2007 9:03 PM
  •  SvanteS wrote:

    Certainly I do!

     

    Myself and my customers use Windows and the .NET Framework.

     

    I write such libraries for international market as well. The latest was for a leading content management system. All UI texts were translated into 13 languages, and the product as such supports extensive features for globalization and localization.

     

    All developer targeted texts are in english. Period. So is the code, comments and documentation.

    I don't have that flexibility.  Don't get me wrong, I would like to avoid that whole localization issue; but I can't.  And I know several other companies that also can't.
    Wednesday, September 12, 2007 9:06 PM
  •  Peter Ritchie wrote:
    I don't have that flexibility.  Don't get me wrong, I would like to avoid that whole localization issue; but I can't.  And I know several other companies that also can't.

     

    I don't want to avoid the whole issue - but I want code, comments and other library developer documentation to be in english.

     

    And this is where best practices come into play. If the default settings of the Microsoft static code analysis tool explicitly tells you that such is the case, this would support you in your wish to avoid this part of the localization issue.

     

    It could preferrably also warn about non-english usage of names, as it already does warn about common misspellings if I recall correctly.

     

    Summing up the arguments so far, for and against localization of exception texts in this thread. I use the term 'developers' below to indicate the intended audience for these texts. That a buggy program may at times expose these texts to a non-intended audience is a very different matter:

     

    For:

    • Some developers in some markets are not strong in english.
    • Some customers want it.

    Against:

    • Developers already needs a large amount of english to be able to use a library, as all names are in english.
    • Developers also need a bit of english just to use the language of choice. All computer languages (with the exception of APL to a large extent) use english as the basis for keywords.
    • Developers already needs to be able to read english to be able to use the documentation for a library. No vendor is able to afford and keep library documentation up-to-date in all target languages.
    • If a bug leads to such text actually being displayed to the end user, the meaning of such a message will escape that user regardless of which language it is written in.
    • Localizing texts has the likely side effect of localizing inserted values such as dates, times, amounts, currency etc in text which rules out automated tools, for example application monitoring tools.
    • It's counter productive. It does not help developers, as it limits the value of communities, existing literature and search tools.
    • It increases the initial development cost by requiring a more time-consuming procedure to add an exception-message.
    • It increases the threshold pain for a developer to add an internal check that may lead to an exception, thus risking lowering code quality by discouraging such checks.
    • It monotonically increases the maintenance costs, as the cost of each new target culture for the library increases by each text that needs localization.
    • Best practices are those that experience has shown to produce the best long-term results in development for such factors as robustness and cost of maintenance. Clearly using english for code, comments and developer documentation is a best practice.

    I believe this issue has arisen due to a very common mistake we developers do - if we can use a feature, we will - sometimes even when it's not appropriate. I've done it, by overarchitecting, by using new cool features just because they are, well cool... I think all experienced developers have at one time or another. It looks to me like the.NET framework team and the FxCop team may inadvertently have fallen into this trap here.

     

    The framework has very extensive and very cool features for globalization and localization of texts. Exception messages are texts. So let's use the text localization features for all texts! But just having a feature available is not motivation enough to use it.

    Thursday, September 13, 2007 5:47 AM
  • I work in Norway and completely agree with Svante.

    The problem Svante describes is one of the first raised when discussing Code Analysis with a German sub-contractor on my current project. He saw this as a big limitation and I agree. Svantes description is very accurate. Exception messages in Norwegian or German is counter productive. 

    This problem is the very reason why we run english versions of all our software (from Windows to Office and Visual Studio). The translated error messages are usually ridiculous and wrong (a popular topic in the Norwegian computer press), and since Norway is a small country you genarally do not find to much information in Norwegian on advanced computer topics. Google (there's the G*** word again) is our best friend when diagnosing software problems.

    Norwegian language in our code is banned. Norwegian is a presentation issue, it is what you show to the end user in the GUI.

    Norwegian is a small language (4 million) so this isn't really a big discussion anymore. Not even the military would ask for Norwegian language in the code anymore. I can se that this may be more of an issue for some of the larger langiages (French in particular). 

    Point is:
    We want help in ensuring that the end user get the language of their choice. 
    At the same time we want our developers to be productive in producing accurate error information in English for efficient 
    diagnostics of problems in the field.

    Nils
    Thursday, September 13, 2007 8:27 AM
  • I am a native English speaker, but the software I develop is used by speakers of more than twenty languages.

     

    I've been hesitant to contribute to this debate because I'm a native English speaker and I'm more interested in hearing what developers of other nationalities have to say on this. However, our decision would also be to restrict exception messages to English, because the technically aware audience such messages are intended for will find it easier to research and diagnose problems that way.

     

    Of course, that includes our own developers, who don't speak the languages our software is translated into. If we were not native English speakers, I can see that we might want to choose a different language as the default for exception messages, but in practice the international developers commenting here also seem to favour English, even though it's not their first language.

     

    It's not possible to draw hard conclusions from this (three developers who are comfortable enough to comment fluently in English on a specific forum may not be representative), but it does seem to me that they make a good case.

     

    Ignoring any convenient practicalitities, what would the "ideal" state of exception messages be? Perhaps there should always be an English message present, with a Regional/Language option in the Control Panel to allow such messages to be displayed in additional languages if they're also available? This would also allow for the bi-lingual requirement mentioned by Peter Ritchie. That requirement is a completely valid one deserving of support, but my impression is that it's less common than simply requiring an English message.

     

    Exceptions might require some sort of unique ID to ensure they can be accurately reported across language barriers, but the most obvious technical solution - a GUID - would of course be a user interface nightmare.

     

    I can't see those things happening in the near future, as they would require non-trivial support from both the operating system and the .NET Framework - for example, a common dialog designed to accommodate a variable number of translations of an exception message - but let's take the long view and hope that someone somewhere will be listening!

    Thursday, September 13, 2007 9:34 AM
  •  SvanteS wrote:

    English is the absolutely best practice we have for code, comments and documentation - when targeted to a developer audience.

     

    Even if I agreed that all developers ought to be able to understand English documentation (which I don't, but that's perhaps a discussion for another day), I really have to wonder why you seem to believe that exception messages are consumed only/mainly by developers.  Has one of your applications never logged an otherwise unhandled exception that is meant to be read and acted upon primarily by the administrator of the application or the machine/network on which it resides?

    Thursday, September 13, 2007 12:28 PM
  •  SvanteS wrote:

    Have you ever seen a software log that will contain meta-data to define which culture was used to localize times, amounts, values etc?

     

    Yes, and I've even implemented such a beast in the form of a log that is localized when it is read rather than when it is written.  Forcing everything to English (and, btw, which English culture variant were you wanting to use for formatting?) isn't the only solution to this sort of problem.

    Thursday, September 13, 2007 12:31 PM
  •  Nicole Calinoiu wrote:
    Even if I agreed that all developers ought to be able to understand English documentation (which I don't, but that's perhaps a discussion for another day), I really have to wonder why you seem to believe that exception messages are consumed only/mainly by developers.  Has one of your applications never logged an otherwise unhandled exception that is meant to be read and acted upon primarily by the administrator of the application or the machine/network on which it resides?

     

    • All developers ought not need be able to understand English documentation. But it's a sad fact that they do need quite a bit of English skills to use an internationally marketed library such as the .NET Framework. And there's no way that will change before machine translation is good enough. And then the understanding issue is moot anyway.
    • As I wrote earlier, library exception messages are targeted towards developers. When they are logged as unhandled, the target audience is still the developer - who now has the task to fix the code to avoid the exception being unhandled in the first place. An unhandled exception is an indication of a bug. It may need fixing in the library itself, or it may need fixing in the caller of the library. The fix may be to log it instead. See below.
    • If the exception is meant to be read and acted upon by the administrator, the correct way is to log this to the application log - not to send it off as an unhandled exception! To do so is a bug. See above.
    • Best practice dictates that all log messages intended for an administrator audience be uniquely identified and docuemented in the operations manual.
    • As previously mentioned, operations manuals are among the documents that on some markets do need localization. In this case, they will typically have an index entry for both the message and the original text in english - along with a localized language version explaining the cause and possible remedies. This is where the localized version of the message should be.

    I am very much aware that many developers all over the world have a difficult time with english. But the cure is not to demand localization of exception messages. If so, it's so much more important that library API naming, programming language, and developer documenation is localized. And this cure is so much worse than the original condition - apart from being economically unfeasible.

     

    You do not want the .NET Framework API localized. See my example in a previous post. So why insist on localizing such a small aspect of the whole issue, exception messages, with reference to poor english skills?

     

    A swedish speaking developer who knows just enough english not to get a program working, and get a library exception thrown in her face, will not be helped by having this exception translated to poor swedish. She will try find a solution using various search tools - and her chance of finding anything at all is reduced immensly by not being able to leverage the global knowledge base on a particular exception message because it is now spread over all the various localized forums etc - if it's there at all. If she wants to post a question, she has no internationally useful reference to provide. Usually it's useless to post such a specific question to a national forum - the audience is too small. The net effect - the localized exception message did not help her - it made it more difficult for her to find a solution.

     

    In fact, the risk is, that she won't even get an exception, just a silently failing program or an exception occurring much too late because the original developers could not afford the time to go through the hoops of placing a localizeable exception message into the code, so they just skipped it.

     

    Just look at this discussion - it's in english on an english forum, and we have at least three or four nationalities take part in the discussion - and an unknown number of non-english speakers who know enough to be able to get gist of it by readin, but are perhaps not comfortable enough to write. If we followed through on the localize everything idea, this discussion would never even take place! 

     

    Having static code analysis by default require localizable resources used for exception messages is harmful and contrary to the best practices we have availble.
    Thursday, September 13, 2007 1:04 PM
  •  Peter Ritchie wrote:

    I have customers that I need to support that requested messages retrieved at run-time contain message text in both "official" languages at the same time.

     

    This is the sort of scenario for which I've typically implemented read-time localization.  However, I've only ever had requests for this functionality in commercial products, never in a single-client project.  I'd probably lean toward choosing write-time multi-lingual localization for a one-off project since it would represent a fairly substantial cost saving for the client.


     Peter Ritchie wrote:

    Ideally, culture-pair support in the framework could solve this issue; but I don't see that happening.  In the meantime I need to support bilingual in other ways.  At this point, bilingual is French/English and English/French; but I wouldn't be surprised if other cultures require bilingual localization that doesn't involve both English or French.  I haven't researched the idea of creating a brand-new culture; but that' seems like a huge PITA with regard to deployment.

     

    A custom culture approach would also be a problem wrt maintaining the resource files.  Of course, you could build the bilingual resource file on the fly from English and French files, but that would perhaps be putting your tooling effort in the wrong place.  Instead, I'd probably create a custom strongly-typed resource code generator that can handle localizing to a list of target cultures rather than just one.  Building a custom code generator like this isn't really all that much work, although there is quite a steep learning curve with the first one.  Then again, for a bit of initial effort, you would get a long-term solution that would require next to no additional effort to maintain.

    Thursday, September 13, 2007 1:11 PM
  •  Nicole Calinoiu wrote:

    Yes, and I've even implemented such a beast in the form of a log that is localized when it is read rather than when it is written.  Forcing everything to English (and, btw, which English culture variant were you wanting to use for formatting?) isn't the only solution to this sort of problem.

     

    That's good! But how could you localize the log when reading it - if it was not written in a known format? Could your code have handled the localization if dates, values, currency amounts, times, etc could appear formatted for an arbitrary culture? What was the result of localizing during reading the formatted date "7/6/5" ?

     

    I'd use the CultureInfo.Invariant culture for all data formatting, write all logs in plain english (us, gp, nz etc is actually quite irrelevant - it's not a spelling bee), use parseable text formats to be able to extract the values from the text, and include a unique log message identifier.

     

    The code would thus write logs using plain english and writing:

     

    throw new InvalidOperationException(String.Format(CultureInfo.InvariantCulture, "Oops an exception happened at DATE={0}", DateTime.Now));

     

    When caught and handled as something that needed logging, that's the message that would be provided, along with the unique id for the log message.

     

    If uncaught, this will help you as the developer to figure out why it was uncaught, without the additional difficulty of having the message being localized to: "Ojsan, ett undantag inträffade på DATUM={0}" just because I the user happened to be running in a Swedish locale, and your companys translation team included Swedish in the list of translations.

     

    Did you also note that the translation team also inadvertently just messed up your log viewer further? Not only will you get the date in a format you can't parse - you wont even find it, because they of course translated your tag as well...

     

    If you have a separate reporting application, it's perfectly fine to have it parse the log file, now that it knows that the values are parseable and formatted with the InvariantCulture, and reformat it using whatever UI culture is in effect, including a possible translation of the original message, since it was identifed by a unique identifier.

     

    It sounds like your "beast" is close to a "beauty", i.e. it does things right - not localizing when writing, but keeping it in a parseable format and localizing when actually presenting to a human. But that's what the current default setting for code analysis discourages!

    Thursday, September 13, 2007 1:22 PM
  •  SvanteS wrote:

    And this is where best practices come into play. If the default settings of the Microsoft static code analysis tool explicitly tells you that such is the case, this would support you in your wish to avoid this part of the localization issue.

     

    I think you've got this the wrong way around.  The CA rules are based largely on the .NET Framework Design Guidelines (http://msdn2.microsoft.com/en-us/library/ms229042.aspx).  It is those guidelines that shape my expectations, not the CA rules themselves.  For a change as large as you are proposing, I would hope to see considerable work by the design guidelines team before the CA team starts making any rule modifications.

    Thursday, September 13, 2007 1:26 PM
  •  Nicole Calinoiu wrote:
     SvanteS wrote:

    And this is where best practices come into play. If the default settings of the Microsoft static code analysis tool explicitly tells you that such is the case, this would support you in your wish to avoid this part of the localization issue.

     

    I think you've got this the wrong way around.  The CA rules are based largely on the .NET Framework Design Guidelines (http://msdn2.microsoft.com/en-us/library/ms229042.aspx).  It is those guidelines that shape my expectations, not the CA rules themselves.  For a change as large as you are proposing, I would hope to see considerable work by the design guidelines team before the CA team starts making any rule modifications.

     

    You're quite right, and I'm (or I thought I was) painfully aware of the wording there. I've read it before starting this thread. Thank you for reminding me to re-read it though! As it turns out, I do not find any strong recommendation to require localizeable exception messages. What I do find here (http://msdn2.microsoft.com/en-us/library/ms229056.aspx) is:

    • Do provide a rich and meaningful message text targeted at the developer when throwing an exception.
    • Consider localizing the exception messages thrown by your components if you expect your components to be used by developers speaking different languages

    There's a strong *Do* indicating that the message is indeed targeted at the developer, which has been one area of discussion in this thread. So if the design guidelines are the final say so, we can lay that one to rest. The messages are for the developer. No-one else.

     

    There's a weaker *Consider* indicating that it's ok, and possibly in some cases preferrable, to localize exception messages. While I do not fully agree (I'd use the wording *Never* ;-), it still supports my main argument 100%.

     

    It's wrong of static code analysis to by default *require* localizable messages for exceptions. There's no support for that in this guideline. As long as guideline reads as it does, the rule should be there, but optional!

     

    And that's really all I want - to be able to use the default settings of static code analysis and have them mirror the strong (shall) requiments of the design guidelines.

    Thursday, September 13, 2007 1:44 PM
  •  Nicole Calinoiu wrote:

    This is the sort of scenario for which I've typically implemented read-time localization.  However, I've only ever had requests for this functionality in commercial products, never in a single-client project.  I'd probably lean toward choosing write-time multi-lingual localization for a one-off project since it would represent a fairly substantial cost saving for the client.

    I've got a strange mix of clients.  It's hard to pin down one solution to multi-lingual localization with the clients I have.  Some require storage in a database, some the filesystem, some the read-time merging.  It's huge up-hill battle trying to change established architectures.
     Nicole Calinoiu wrote:
    A custom culture approach would also be a problem wrt maintaining the resource files.  Of course, you could build the bilingual resource file on the fly from English and French files, but that would perhaps be putting your tooling effort in the wrong place.  Instead, I'd probably create a custom strongly-typed resource code generator that can handle localizing to a list of target cultures rather than just one.  Building a custom code generator like this isn't really all that much work, although there is quite a steep learning curve with the first one.  Then again, for a bit of initial effort, you would get a long-term solution that would require next to no additional effort to maintain.

    I'm almost to the point of writing something like this.  There's lots of problems with a custom culture solution that make it a less than flexible solution.  Given the support for specific cultures in resources, a custom resource manager that performs the merging (and whatever support code/infrastructure is required) is probably the best route.  Assuming, I can get all my clients to break free of their existing infrastructures (On paper it shouldn't be too hard; the database solution, for example, how do you display a bilingual message to the user that the database is inaccessible?:-)
    Thursday, September 13, 2007 1:45 PM
  •  SvanteS wrote:

    And that's really all I want - to be able to use the default settings of static code analysis and have them mirror the strong (shall) requiments of the design guidelines.

    As would everyone else; if the defaults matched your preferences then they wouldn't match other people's preferences.  There's no way to have default settings that are perfect for everyone, that's why you can disable rules.  Microsoft doesn't even use the default settings...
    Thursday, September 13, 2007 1:52 PM
  •  Peter Ritchie wrote:
     SvanteS wrote:

    And that's really all I want - to be able to use the default settings of static code analysis and have them mirror the strong (shall) requiments of the design guidelines.

    As would everyone else; if the defaults matched your preferences then they wouldn't match other people's preferences.  There's no way to have default settings that are perfect for everyone, that's why you can disable rules.  Microsoft doesn't even use the default settings...

     

    The default settings should not match my preferences. The default settings should match the strong (do/shall) requirements of the design guidelines, no more, no less.

    Thursday, September 13, 2007 1:57 PM
  •  SvanteS wrote:
     Peter Ritchie wrote:
     SvanteS wrote:

    And that's really all I want - to be able to use the default settings of static code analysis and have them mirror the strong (shall) requiments of the design guidelines.

    As would everyone else; if the defaults matched your preferences then they wouldn't match other people's preferences.  There's no way to have default settings that are perfect for everyone, that's why you can disable rules.  Microsoft doesn't even use the default settings...

     

    The default settings should not match my preferences. The default settings should match the strong (do/shall) requirements of the design guidelines, no more, no less.

    No, they should not.  The "Guidelines" don't mention things like Cyclomatic Complexity, or the Mobility warnings, etc.  I'm sure there's lots of other CA rules that aren't in the "Guidelines", I'm not going to waste my time attempting to match each rule to something in the "Guidelines".  Also, what happens when there's language/class-library additions that could really use a new rule; must it be denied until a new version of the "Guidelines" is published, of course not.
    Thursday, September 13, 2007 2:18 PM
  •  Peter Ritchie wrote:
    No, they should not.  The "Guidelines" don't mention things like Cyclomatic Complexity, or the Mobility warnings, etc.  I'm sure there's lots of other CA rules that aren't in the "Guidelines", I'm not going to waste my time attempting to match each rule to something in the "Guidelines".  Also, what happens when there's language/class-library additions that could really use a new rule; must it be denied until a new version of the "Guidelines" is published, of course not.

     

    The difference of opinion now seems to have boiled down to if there should be an opt-in or an opt-out strategy with respect to the default settings.

     

    We're agreed that exceptions messages are targeted to the developer, and that there is no support in the guidelines for requiring localizable texts for exceptions.

     

    We all agree that a rule for localizable string usage for exceptions may be useful under certain conditions.

     

    It is my strong feeling that for static code analysis, an opt-in strategy is better than an opt-out.

     

    The reason is very simple.

     

    It's so much easier for a developer to disable a rule than to fix a problem. We do not want to establish this as the standard procedure.

     

    If the default settings are such that your really should have a good reason to disable rules, that's a good thing.

     

    The default settings should be so that the majority number of projects do not have any valid excuses (except tons of legacy code ;-) to turn off any of the default settings.

     

    In addition to default settings there should be many more rules included, that may be included optionally - for example when the design guidelines says Consider rather than Do, or other best practices dictates that a rule is beneficial.

     

    With the opt-out strategy few if any projects will be able to say "Our code passes static code analysis". We'll have to say "Our code passes the custom set of static code analysis rules that we have decided to enforce.". The latter is a much weaker statement, that really means nothing at all.

     

    "Our code passes static code analysis" with the opt-in strategy may say "Our code conforms to the coding guidelines strong requirements according to static code analysis" - that's a pretty strong and useful statement.

     

    An alternative approach is of course to define multiple standard well-defined sets of rules - will VS 2008 support this? (I'm not using the beta so I have no idea). If there's a named rule-set out of the box, perhaps named "Microsoft Coding Guidelines" - that does not include the exception text localization snafu, that would be a good  thing.

     

    The point is not if I can make such a rule set. The point is that it is pre-defined - that's when there's any strength in claiming conformance.

    Thursday, September 13, 2007 2:40 PM
  •  SvanteS wrote:

    The difference of opinion now seems to have boiled down to if there should be an opt-in or an opt-out strategy with respect to the default settings.

    I see no discernable difference between an ability to opt-in or opt-out.

     SvanteS wrote:

    We're agreed that exceptions messages are targeted to the developer, and that there is no support in the guidelines for requiring localizable texts for exceptions.

    I have no idea what we agree on with regard to exception messages; but I don't agree with your above statement.  Exception messages may be "targeted" to developers; but end-user sometimes see them too.  Displaying gibberish (which is what they get if they can't read the language of the message) is never a good thing.

     SvanteS wrote:

    We all agree that a rule for localizable string usage for exceptions may be useful under certain conditions.

     

    It is my strong feeling that for static code analysis, an opt-in strategy is better than an opt-out.

     

    The reason is very simple.

     

    It's so much easier for a developer to disable a rule than to fix a problem. We do not want to establish this as the standard procedure.

    I agree that arbitrary code changes to "get around" or "remove" or "avoid" code analysis warnings can be a bad thing.

     SvanteS wrote:

    If the default settings are such that your really should have a good reason to disable rules, that's a good thing.

     

    The default settings should be so that the majority number of projects do not have any valid excuses (except tons of legacy code ;-) to turn off any of the default settings.

     

    In addition to default settings there should be many more rules included, that may be included optionally - for example when the design guidelines says Consider rather than Do, or other best practices dictates that a rule is beneficial.

    What is and isn't useful needs to be defined for each project.  If you're working on a Windows Service, for example, message localization may be much less of a priority than if you're working on a WinForms application.  There's no useful subset "default" that Microsoft could define that could be applied in both of these circumstances.

     SvanteS wrote:

     

    With the opt-out strategy few if any projects will be able to say "Our code passes static code analysis". We'll have to say "Our code passes the custom set of static code analysis rules that we have decided to enforce.". The latter is a much weaker statement, that really means nothing at all.

     

    "Our code passes static code analysis" with the opt-in strategy may say "Our code conforms to the coding guidelines strong requirements according to static code analysis" - that's a pretty strong and useful statement.

    An alternative approach is of course to define multiple standard well-defined sets of rules - will VS 2008 support this? (I'm not using the beta so I have no idea). If there's a named rule-set out of the box, perhaps named "Microsoft Coding Guidelines" - that does not include the exception text localization snafu, that would be a good  thing.

     

    The point is not if I can make such a rule set. The point is that it is pre-defined - that's when there's any strength in claiming conformance.

    I don't know where you got the idea that projects should "pass static code analysis" (and I would say the opposite, that "Our code passes static code analysis" is meaningless).  This isn't a recommendation coming from Microsoft.  Microsoft recommends (and implements) profiles of rules that a project must pass (or specific code must be reviewed before suppressing the rule for that code) for individual projects or development groups.  This is not something Microsoft can define or mandate; each project team must review the rules to define what they think is important and disable the rules they don't feel are important or apply to their project.

     

    Best case, Microsoft could add an ability to manage rule profiles; but they can't mandate what "pass" or "fail" means for a specific project.  The only thing Microsoft could do that would be useful for every developer is either to enable all rules or disable all rules.  There's no subset of rules that would make everyone (anyone) happy.  Considering out of the box you have to manually run Code Analysis, disabling all rules (what you call "opt-in") makes no sense.

    Thursday, September 13, 2007 3:21 PM
  •  Peter Ritchie wrote:

    I see no discernable difference between an ability to opt-in or opt-out.

    It's not about the ability, it's about the default strategy related to the defaults.

     Peter Ritchie wrote:

    Exception messages may be "targeted" to developers.

    The Microsoft design guidelines for libraries states differently. You're entitled to your personal view of course.

     Peter Ritchie wrote:

    If you're working on a Windows Service, for example, message localization may be much less of a priority than if you're working on a WinForms application.

    This discussion is about libraries, not Windows Forms applications or any kind of application.

     Peter Ritchie wrote:

    The only thing Microsoft could do that would be useful for every developer is either to enable all rules or disable all rules.

    Obviously that is not so. CA is just an extension of compiler warnings which implements 4 pre-defined levels. The compiler supports levels and enabling or disabling individual rules, and most developers find the compiler quite useful.

     Peter Ritchie wrote:

    There's no subset of rules that would make everyone (anyone) happy.

    Yes there are subsets that makes some, probably many, people happy. See above.

     Peter Ritchie wrote:

    Considering out of the box you have to manually run Code Analysis, disabling all rules (what you call "opt-in") makes no sense.

    I do not call disabling all rules opt-in. Please re-read my post.

     

    This discussion is teetering on a fine edge at this point, so I'll conclude my participation in this particular part of the thread. Thank you for your views on this matter, I really do appreciate them and I hope the community has found the discussion illuminating to some degree. I have. I'm leaving the last word to you!

     

    In my professional opinion localization of Exceptions-messages is harmful, and CA and FxCop will be more useful to more developers and promote the writing of libraries that are better for more developers if rule CA1303 was modified so it did not by default fire on arguments to System.Exception-derived classes constructors.

    Thursday, September 13, 2007 4:38 PM
  • I really don't care for your arguments with svantes. I do, however, take umbrage with your rather narrow and conceited views that show an alarmingly disproportionate amount of ignorance towards others. This in turn, displays a tendency, suggesting complete arrogance. Please don't 'tar others with your brush'. Your delivery of English in your arguments is far from pleasant and leaves a great deal to considered. The level of intellect that is visible in your replies is by no means such that you can warrant such a broad and therefore meaningless statement.

     

     Svante wrote:
    No, no, no. You've got it all wrong! In fact, the local Swedish computer magazines regularily print bloopers from the Microsoft Windows messages that are so garbled that the actual message is very much lost in translation. The only thing that sometimes saves us and lets us do our jobs is when error codes or other non-changing, non-localized information is made part of the translated message.

    That's a translation issue and has nothing to do with code analysis.  English-speaking people often poorly word English text, it's not unique to translation.

    Friday, May 23, 2008 8:55 AM
  •  egdim wrote:

    I really don't care for your arguments with svantes. I do, however, take umbrage with your rather narrow and conceited views...

     

    I can't make out who this is directed against, but in any case I do take umbrage with sweeping and unsubstantiated claims, ending with a harsh attack on a person, where you claim to see signs of an inferior intellect. Please refrain from attacking the person, and stick to the issue. You might want to edit your post.

     egdim wrote:

     

     

     Svante wrote:
     
    No, no, no. You've got it all wrong! In fact, the local Swedish computer magazines regularily print bloopers from the Microsoft Windows messages that are so garbled that the actual message is very much lost in translation. The only thing that sometimes saves us and lets us do our jobs is when error codes or other non-changing, non-localized information is made part of the translated message.


     
     

    That's a translation issue and has nothing to do with code analysis.  English-speaking people often poorly word English text, it's not unique to translation.

     

    It has to do with code analysis because this thread is about an FxCop rule leading to exception texts being localized, and the above is a supporting argument, one of many, why this is a bad thing.

     

    What do you think "irregularities with unauthorized memory" means? That's the tranlsation you might get, if the message "illegal memory access violation" was originally written in Swedish, and then translated to English. It's possible after the fact to understand, but since there are accepted technical terms, they are better than a general translation. The point here is that there are no accepted translations for many very specific technical terms into some languages - Swedish being one example.

     

    In English writing about computers, the terms "illegal", "memory" and "access violation" have some specific meanings, and they are hard to translate in many cases.

     

    The above was a supporting argument for why localization of exceptions messages is a bad thing, and why I would like to have FxCop refrain from encouraging that behavior.

     

    That's why it indeed is a code analysis issue.

     

    PS - It's generally not considered good practice to post to old inactive threads. The English technical term is "necroposting" (I don't even want to think about what that'll come out to in Swedish...).

     

    PSS - This post was edited because it simply did not post what I wrote.

    Friday, May 23, 2008 9:42 AM