<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 14, 2011 at 3:33 PM, Richard Carlsson <span dir="ltr"><<a href="mailto:carlsson.richard@gmail.com">carlsson.richard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 07/13/2011 09:19 PM, Alex Arnon wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We're building a nontrivial Erlang application, which will provide a<br>
potentially high-volume, public RESTful Web Service. As part of the API,<br>
we will be providing both informative text (status, labels, layout<br>
templates) and error messages. A twofold question, then, to the<br>
experienced Grandmasters in the audience:<br>
1. How have you implemented localization of text? This includes<br>
parameterized format strings.<br>
</blockquote>
<br></div>
At Klarna we are using (and maintaining) the gettext library, and it works very well. You'll find the latest version at <a href="https://github.com/etnt/gettext" target="_blank">https://github.com/etnt/<u></u>gettext</a> - the version at Jungerl is very much out of date.<br>

<br>
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:<br>

<br>
  ?STXT("Hello, $name$! Today's date is $date$ and the time is $time$.",<br>
        [{date, current_date_as_string()},<br>
         {time, current_time_as_string(),<br>
         {name, customer_name(CustomerID)}])<br>
<br>
For the documentation (not very up to date, sorry), run 'make docs' and open doc/index.html in a browser.<br>
<br>
Tobbe also made some support for gettext in rebar:<br>
<a href="http://www.redhoterlang.com/entry/138dc1b1f8720f5c4f38864e4f0c338f" target="_blank">http://www.redhoterlang.com/<u></u>entry/<u></u>138dc1b1f8720f5c4f38864e4f0c33<u></u>8f</a><br>
<br>
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:<br>
<br>
<a href="http://www.redhoterlang.com/entry/8af2641026c0dfa27e54cb0da57eb392" target="_blank">http://www.redhoterlang.com/<u></u>entry/<u></u>8af2641026c0dfa27e54cb0da57eb3<u></u>92</a><br>
<br>
<a href="http://www.youtube.com/watch?v=UdhE2YOkBCU" target="_blank">http://www.youtube.com/watch?<u></u>v=UdhE2YOkBCU</a><br>
<br>
<a href="http://www.redhoterlang.com/entry/98951c7196e0d91999bb238de5defe47" target="_blank">http://www.redhoterlang.com/<u></u>entry/<u></u>98951c7196e0d91999bb238de5defe<u></u>47</a><div class="im"><br>
<br></div></blockquote><div><br>Thank you, this looks promising!<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Has anyone used composite error values? For example, instead of<br>
{error, badarg}, use {error, {badarg, [{arg, ArgumentName}, {message,<br>
LocalizedMessageId}, {message_args, [...]}... Should we steer clear of<br>
these, and if so, what alternative would you suggest?<br>
</blockquote>
<br></div>
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.<br>
<font color="#888888">
<br>
    /Richard<br>
</font></blockquote></div><br>I was thinking of two purposes for the structured Reason:<br>1. The error handling code - which may receive extra information regarding the error itself.<br>2. Logging code - the handling code can forward the error to a logger, with attached message format + args etc.<br>
Localization of the message is probably pointless, I agree - I kind of overloaded [2] with [1]. :)<br><br></div>