[erlang-questions] Best Practices: Localization of Erlang Applications. Also, Error Messages!

[Steve Davis]

Given that "strings" are either ambiguous or implicitly constrained
inventions of data representation, then you may consider applying
something along the lines of:

-record(text, {value, charset = utf8, locale = 'us-en'}).

...to all user-viewable messages. The transformation would use
whatever hideously ambiguous or implicitly constrained "string" that
bubbles up from infrastructure as the "key" to that tuple value.

BTW This problem isn't really an erlang/otp but one that every
platform that I have ever investigated. What makes erlang different is
that you can easily forsee a potential, and implementable, solution to
this legacy issue in CS.

/s

On Jul 13, 2:19 pm, Alex Arnon <alex.ar...@REDACTED> wrote:
> Hi All,
>
> We're building a nontrivial Erlang application, which will provide a
> potentially high-volume, public RESTful Web Service. As part of the API, we
> will be providing both informative text (status, labels, layout templates)
> and error messages. A twofold question, then, to the experienced
> Grandmasters in the audience:
> 1. How have you implemented localization of text? This includes
> parameterized format strings.
> 2. Has anyone used composite error values? For example, instead of {error,
> badarg}, use {error, {badarg, [{arg, ArgumentName}, {message,
> LocalizedMessageId}, {message_args, [...]}... Should we steer clear of
> these, and if so, what alternative would you suggest?
>
> Thanks in advance!
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions