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

[Alex Arnon]

On Thu, Jul 14, 2011 at 3:33 PM, Richard Carlsson <
carlsson.richard@REDACTED> wrote:

> On 07/13/2011 09:19 PM, Alex Arnon wrote:
>
>> 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.
>>
>
> At Klarna we are using (and maintaining) the gettext library, and it works
> very well. You'll find the latest version at https://github.com/etnt/**
> gettext <https://github.com/etnt/gettext> - the version at Jungerl is very
> much out of date.
>
> In particular, you'll probably want to use the new (not yet documented)
> macro ?STXT(...) instead of the ?TXT(...) macro. This is less error prone,
> since the fields and their meaning are more easily identified and do not
> have to be listed in order of occurrence. For example:
>
>  ?STXT("Hello, $name$! Today's date is $date$ and the time is $time$.",
>        [{date, current_date_as_string()},
>         {time, current_time_as_string(),
>         {name, customer_name(CustomerID)}])
>
> For the documentation (not very up to date, sorry), run 'make docs' and
> open doc/index.html in a browser.
>
> Tobbe also made some support for gettext in rebar:
> http://www.redhoterlang.com/**entry/**138dc1b1f8720f5c4f38864e4f0c33**8f<http://www.redhoterlang.com/entry/138dc1b1f8720f5c4f38864e4f0c338f>
>
> To make it easier to actually get the translations into the system, or
> update translations as the original text changes, you may also want to use
> the Polish tool:
>
> http://www.redhoterlang.com/**entry/**8af2641026c0dfa27e54cb0da57eb3**92<http://www.redhoterlang.com/entry/8af2641026c0dfa27e54cb0da57eb392>
>
> http://www.youtube.com/watch?**v=UdhE2YOkBCU<http://www.youtube.com/watch?v=UdhE2YOkBCU>
>
> http://www.redhoterlang.com/**entry/**98951c7196e0d91999bb238de5defe**47<http://www.redhoterlang.com/entry/98951c7196e0d91999bb238de5defe47>
>
>
>
Thank you, this looks promising!



>
>  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?
>>
>
> Who is expected to read these messages? End users, or developers? For
> developers, it's better if the message is in plain English. First, you may
> have people from different countries working on your code. Second, it's
> harder to google for the error message if the one you got was in Spanish,
> but the only people who have previously reported the problem got their
> messages in German. At the very least, always provide a summary or short
> identifier in English.
>
>    /Richard
>

I was thinking of two purposes for the structured Reason:
1. The error handling code - which may receive extra information regarding
the error itself.
2. Logging code - the handling code can forward the error to a logger, with
attached message format + args etc.
Localization of the message is probably pointless, I agree - I kind of
overloaded [2] with [1]. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110714/5d7505a0/attachment.htm>