<html><body>
<p><font size="2" face="sans-serif">Hi, Juergen</font><br>
<br>
<font size="2" face="sans-serif">Thank you for your response. It's very normal that people have different opinions.</font><br>
<br>
<font size="2" face="sans-serif">Firstly, I would argue REST API return message is not only programmatic error messages,</font><br>
<font size="2" face="sans-serif">but also user (administrators, or tenants of public cloud) facing messages.</font><br>
<br>
<font size="2" face="sans-serif">Typically the API return messages are the explain errors/failures. </font><br>
<font size="2" face="sans-serif">The question is whether these messages would be shown directly to end users.</font><br>
<font size="2" face="sans-serif">In some cases, if the client side doesn't want to handle those error messages, the return messages will be shown directly to end users, </font><br>
<font size="2" face="sans-serif">e.g."Instance does not exist" or "Instance is not a member of specified network"</font><br>
<font size="2" face="sans-serif">Programmers may be well educated. </font><br>
<font size="2" face="sans-serif">But some administrators, or even tenants of the public cloud, may not feel comfortable to English strings.</font><br>
<font size="2" face="sans-serif">So I think, the translation of user facing messages is valuable to OpenStack selling.</font><br>
<font size="2" face="sans-serif">The API return messages should be translated into client specified language,</font><br>
<font size="2" face="sans-serif">because OpenStack server may be in US, but the access of public cloud may be from China.</font><br>
<br>
<font size="2" face="sans-serif">Secondly, I would say both translation and not translation have advantages/pros and disadvantages/cons.</font><br>
<font size="2" face="sans-serif">The thorough solution is to introduce coding system to messages, assign a universal identifier to each message.</font><br>
<font size="2" face="sans-serif">Thus messages can not only be searched by strings, but also searched by identifier.</font><br>
<font size="2" face="sans-serif">That will solve the searching issue.</font><br>
<font size="2" face="sans-serif">Eric Windisch has a very good description of universal identifier. </font><br>
<font size="2" face="sans-serif">If you are interested, you can read it here: <a href="http://lists.openstack.org/pipermail/openstack-dev/2012-November/002396.html">http://lists.openstack.org/pipermail/openstack-dev/2012-November/002396.html</a></font><br>
<font size="2" face="sans-serif">Of course, if google can support multiple languages search, it will be wonderful.</font><br>
<br>
<font size="2" face="sans-serif">Daisy</font><br>
<br>
<br>
<tt><font size="2">"Juergen Brendel (jbrendel)" <jbrendel@cisco.com> wrote on 2012/11/16 02:44:18:<br>
<br>
> "Juergen Brendel (jbrendel)" <jbrendel@cisco.com> </font></tt><br>
<tt><font size="2">> 2012/11/16 02:44</font></tt><br>
<tt><font size="2">> <br>
> Please respond to<br>
> OpenStack Development Mailing List <openstack-dev@lists.openstack.org></font></tt><br>
<tt><font size="2">> <br>
> To</font></tt><br>
<tt><font size="2">> <br>
> OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font></tt><br>
<tt><font size="2">> <br>
> cc</font></tt><br>
<tt><font size="2">> <br>
> Subject</font></tt><br>
<tt><font size="2">> <br>
> Re: [openstack-dev] Translate REST API return message to a different<br>
> language as log translation</font></tt><br>
<tt><font size="2">> <br>
> </font></tt><br>
<tt><font size="2">> Hello!</font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> I would question the value of translating programmatic error <br>
> messages. In a technical product with a relatively small user base <br>
> (such as OpenStack), the translation of error messages is counter-<br>
> productive, I would argue. The reason is: How do you ¡°google¡± for a <br>
> solution to a problem you have or how do you discuss it online with <br>
> others in the community? You¡¯ll be lucky to find anyone in the world<br>
> that has the same issue and maybe has posted a solution to it, but <br>
> now you also need to find someone who uses the same language setting<br>
> or deal with on-the-fly translations in discussions which are also <br>
> error prone.</font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> OpenStack is not Facebook or Twitter, it¡¯s not a consumer or end-<br>
> user service. OpenStack¡¯s users are clearly very technical. I¡¯m not <br>
> a native English speaker myself, but I¡¯d think all of us working in <br>
> this industry will speak enough English to get a rough idea of what <br>
> an error will be about and how to ask for help online. In English. </font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> Juergen</font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> From: Ying Chun Guo [<a href="mailto:guoyingc@cn.ibm.com">mailto:guoyingc@cn.ibm.com</a>] <br>
> Sent: Friday, November 16, 2012 5:29 AM<br>
> To: OpenStack Development Mailing List<br>
> Subject: [openstack-dev] Translate REST API return message to a <br>
> different language as log translation</font></tt><br>
<tt><font size="2">> </font></tt><br>
<tt><font size="2">> Hi, all<br>
> <br>
> When fault happens, the REST API response messages will contain a <br>
> string as an explanation. Currently, the string of explanation is <br>
> translated based on server side locale. I got a new requirement: to <br>
> translate REST API response messages based on the requested language<br>
> from client side.<br>
> <br>
> For example, if the client is in China and sends a request with a <br>
> parameter "Accept-Language: zh-CN" in HTTP header, the explanation <br>
> in the REST API response should be translated into Chinese. If the <br>
> client is in France and sends a request with a parameter "Accept-<br>
> Language: fr-FR" in header, the explanation in the REST API response<br>
> should be translated into French. Regardless of the response <br>
> messages translation, the log in server side will be translated <br>
> based on server side locale setting.<br>
> <br>
> In order to fulfil this request, I think, the most difficult thing <br>
> is to separate the logic of LOG and API response. Because currently,<br>
> the API response will be written to the LOG exactly as it is. (Refer<br>
> to ResourceExceptionHandler.__exit__(self, ex_type, ex_value, <br>
> ex_traceback) in Nova/nova/api/openstack/wsgi.py) But I need the <br>
> response message in the language specified by client, and the LOG in<br>
> the language specified by server locale.<br>
> <br>
> I have two solutions for this requirement.<br>
> <br>
> One is to maintain a map between server locale translation and <br>
> client requested translation in gettextutils.py. When raising a <br>
> webob.exc.HTTPException, still use the server locale translation as <br>
> the explanation, which will be written to log. When composing the <br>
> response JSON message (Refer to Fault.__call__(self, req) in Nova/<br>
> nova/api/openstack/wsgi.py), get the client requested translation <br>
> from the map and put it in the response JSON object.<br>
> <br>
> The other is to remove log writing from API response logic, which <br>
> means, removing the log statements in <br>
> ResourceExceptionHandler.__exit__(self, ex_type, ex_value, ex_traceback) in <br>
> Nova/nova/api/openstack/wsgi.py. Add explicit LOG statement before <br>
> raising a webob.exc.HTTPException. For example:<br>
> <br>
> msg = _('Invalid is_public filter [%s]') % req.params['is_public'] <br>
> raise webob.exc.HTTPBadRequest(explanation=msg) <br>
> <br>
> will be changed to:<br>
> <br>
> msg = _gettext('Invalid is_public filter [%s]')<br>
> LOG.error(_(msg) % req.params['is_public'])<br>
> raise webob.exc.HTTPBadRequest(explanation=_<br>
> (msg,req.get_accept_language()) % req.params['is_public']) <br>
> <br>
> Method _gettext(string) will do nothing to the string, just for <br>
> string extraction. Method _(msg) will be changed to accept the <br>
> second parameter _(msg, locale).<br>
> <br>
> Please let me know your opinion to these two solutions. Which one do<br>
> you prefer? Or do you have better solutions?<br>
> <br>
> Regards<br>
> Ying Chun Guo (Daisy)<br>
> China Standards and Open Source Team<br>
> Emerging Technology Institute (ETI)<br>
> IBM China Development Lab<br>
> Tel:(86-10)82453491<br>
> Email: guoyingc@cn.ibm.com<br>
> Address: 1F Tower B, Diamond Building 19 Zhongguancun Software Park, <br>
> 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></tt></body></html>