- From: Addison Phillips <notifications@github.com>
- Date: Mon, 20 Sep 2021 10:40:28 -0700
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/issues/1024/923138426@github.com>
@domenic Java has some (quite old and not-well-designed) support for localizable exceptions. I've done quite a lot with building localizable exception support in different frameworks in that language as a result. A key factor in designs of this nature is what is called the "three locale problem": the data or resource being operated on is often in a language/has a locale. The service or system's operator has a preferred locale. And the client/caller has a locale. Each of these may need to resolve an exception to a human-readable string. The argument against localizable exceptions is generally "it's for debugging only" (until it's the only value available for the user experience) or that maybe this was intentional in the language's design. I think it is okay to hardcode your log messages, but any message that can be seen by a user (!= developer) probably shouldn't be. @bathos The best practice is (or rather, should be) locale-neutral errors with well-defined error *values*. This allows the consumer to localize the message and reduces the pain of trying to match up strings between systems/specifications. Data values can also be sent down the wire in a locale neutral fashion. However, this doesn't work so well when specs design non-localizable/non-locale-neutral exceptions from the start. That is, this can never be localized: ``` return new FooException("Why can't we have nice things?"); ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/issues/1024#issuecomment-923138426
Received on Monday, 20 September 2021 17:40:40 UTC