Misc fixes for protobuf migration

[Phergus]

Identify the Bug or Feature request

Issue #3254

Description of the Change

AppActions - showError() call incorrectly using t.getCause()
MapTool - log.error() was using message key and not the message string.
Zone - added check for aStarRounding being null to readResolve().

Possible Drawbacks

None expected.

Documentation Notes

n/a

Release Notes

Failing to load a campaign now more likely to produce a useful message.

---

This change is 

[kwvanderlinde]

Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @Phergus)

[Azhrei]

I believe the use of the key inside log.error() was because a translated string in the log file is not helpful to the developers. If an error message is translated to German, for example, I'm not going to know what it says/means. Instead, logging the key will always produce a string that is meaningful, even if I don't know German (which I don't).

Granted, messages that the user should see should be translated, but I'm not sure that's the case for logging messages (although an argument can certainly be made).

[Phergus]

Well in this case the only thing coming out was the English key string and nothing else so not particularly helpful to anyone.

I see your point but a developer working in other languages might like the messages to be in their preferred language. As someone who ends up looking at MT output in other languages fairly regularly I don't find it difficult to deal with.

[Azhrei]

Hm, maybe the log file should include the key and the translated text? The key string would allow a search through the code to find where it was generated, while the translated text would be useful to someone using a different language, as you say. Even the person using German might like to find out where the message was coming from…?

[Phergus]

Hm, maybe the log file should include the key and the translated text?

That's not a terrible idea but really we should not be outputting key strings that are in the i18n files if we are going to use them as is. The translators are dutifully going through and translating them wasting their time.

Locating where the translated message comes from is hardly challenging. A first search of the source would point to the i18n key and from there a second search, or just Find Usages from the IDE, will take them to the likely spot. This is something I end up doing a lot already as users typically report what is the error messages.

[Azhrei]

Hm, maybe the log file should include the key and the translated text?

That's not a terrible idea but really we should not be outputting key strings that are in the i18n files if we are going to use them as is. The translators are dutifully going through and translating them wasting their time.

Huh? Now I'm confused. The translations are used by the UI, as in "user interface", so the users definitely want to see translated strings and no one is "wasting their time".

But log files are rarely (if ever) looked at by users. Those files are 100% for developers to track down problems.

Locating where the translated message comes from is hardly challenging. A first search of the source would point to the i18n key and from there a second search

And where do you get the key from?

Are you going to search the German translation to find the string, then use that key to search the source code? And what if the same translated string is used by multiple keys?

I'm confused about why displaying the key seems such a distraction. I'm probably just missing something obvious, but so far I just don't see it.