A Localizer's Nightmare: Security Backend Error Messages

We had the same problems with the Spanish translation time ago, Ricardo had to ask us several times to get something that doesn't sound "strange".

Good luck!

We had some healthy discussion in nl-NL about XML parsing error messages and other error messages in Mozilla. As a (web tech) programmer, I quite frequently encounter these, and the original strings were just extremely awkward.

The problem is twofold. First, where do you draw the line between translating technical terms and when not. Second, if you do translate something, how are you sure that you’re translating it correctly? There is a lot of terminology that implies specific things, and does not mean the same as another word that’s normally roughly synonymous, but not in the context of that technology. For example, ‘well-formed’ does not translate to ‘valide’ (valid).

Especially if you’re not very familiar with the particular technologies, it’s difficult to know if your translations strike the right balance or even convey the proper message. And because they’re error messages, it’s important that they do point to the problem. Some translations originally even said something completely different than the original English one.

But we got it more or less right now, I think. We used Dutch where there was commonly used Dutch, and the phrasings are now such that they will actually help the programmer, instead of work against him :).

~Grauw

A few general questions (and maybe a disclaimer upfront: this is a more general comment about error messages and l10n than a critique of your work): are these messages visible to average users? If so, could they really do something to fix the problem (esp. in the case of the bad padded SSL record, I am pretty sure my Dad has no clue what to do; heck, even I don't have an idea)?

Anyway, considering the visibility of the messages (user vs. log only) do they really need to be localized? I mean, most development related documentations are written in English - I am pretty sure "SSL block padding" is a far better search phrase than "SSL Block-Auffüllung", and to the technical savy user, the latter would not really give a clue about the error (maybe it is my age and the time I started programming - l10n was a rather rare thing in normal applications and unknown in API documentations - but localized error messages are a PITA).

The conclusion (of this rather unrelated and misplaced comment) might be to use a more general error message like "Something gone boom [here the one to blame could be named, e.g. the application, the connection or the server failed]. If you studied computer science, click here to view the details. Otherwise, try to reload the page." (not in these exact words but you should get the general idea). Translating for the sake of having a l10n story is not always good.

Sorry for having choosen your innocent post about the troubles of a translater for my rant about my error messages and general l10n pet peeves

Björn, as for not translating it all, I think that if you are careful in your translation it is possible to properly translate the error messages.

There are a lot of people who are not very familiar with English or the English terminology, and I think having the error described in their native language most definitely helps their understanding.

If you assume that the technical user knows English, I think you are putting up a barrier for a lot of would-be or starting programmers. Even if it were so that all programmers know English, that only means that there are a lot of people out there who would like to program as well but find it too difficult because of the language barrier.

~Grauw

p.s. I blogged my earlier reply a little more extensively at http://www.grauw.nl/blog/entry/404

I would dare say that most of the cryptic stuff that ends up in the users face is a bug in Firefox that needs to be fixed. Localizers should never need to touch stuff like this.

The reason is simple: if the error message is so difficult to understand that only people who are intimately familiar with the technologies or the product would have any hope of understanding the message, let alone know what to do, the error message has failed its purpose. Sure, log all the technical details in a log file, but give the users something that they'll understand and offer them some options on what to do.

HT: How do you know what is too cryptic for every Firefox user out there? And actually, this file is probably used by every app that uses NSS, not just by Firefox - which makes this decision even harder, as you need to know what every NSS user (Thunderbird/SeaMonkey/Sunbird/Joost/Flock/Songbird/AllPeers/... user) finds too cryptic or - on the other side of the story - too little helpful (in case they see a generic message).

I kinda second Björn's and HT's comments. Maybe these messages is something that Jonathan should re-evaluate. And it'd be really good to understand how those are exposed, too. Might be that they're actually popping up in neterror pages now.

There's probably more information in https://bugzilla.mozilla.org/show_bug.cgi?id=107491.

PS: KaiRo, way to go with richer content in bug comments ;-), and personal data rememberance, too. Oh, and I recall that trackback data sent by you is way more verbose than what other systems do, too.