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

[Håkan Stenholm]

The thread "[erlang-questions] utf-8 PB" in the erlang mailing list 
(archive) during 2010-06-16/17/18 may be of interest to you.
I (Håkan Stenholm) wrote a bunch of replies about using gettext and .po 
files in that thread.

I used to work with internationalization/localization issues at Klarna 
back in 2005-2010, but not having worked there (or with erlang) since 
2010-04 makes me fairly useless as a source for current information.



On 2011-07-14 16.46, Alex Arnon wrote:
>
>
> On Thu, Jul 14, 2011 at 3:33 PM, Richard Carlsson 
> <carlsson.richard@REDACTED <mailto: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 - 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/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/8af2641026c0dfa27e54cb0da57eb392
>
>     http://www.youtube.com/watch?v=UdhE2YOkBCU
>
>     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]. :)
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110715/1c595105/attachment.htm>