Open Stack

Hello!

I would question the value of translating programmatic error messages. In a technical product with a relatively small user base (such as OpenStack), the translation of error messages is counter-productive, I would argue. The reason is: How do you "google" for a solution to a problem you have or how do you discuss it online with others in the community? You'll be lucky to find anyone in the world that has the same issue and maybe has posted a solution to it, but now you also need to find someone who uses the same language setting or deal with on-the-fly translations in discussions which are also error prone.

OpenStack is not Facebook or Twitter, it's not a consumer or end-user service. OpenStack's users are clearly very technical. I'm not a native English speaker myself, but I'd think all of us working in this industry will speak enough English to get a rough idea of what an error will be about and how to ask for help online. In English.

Juergen



From: Ying Chun Guo [mailto:guoyingc at cn.ibm.com]
Sent: Friday, November 16, 2012 5:29 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Translate REST API return message to a different language as log translation


Hi, all

When fault happens, the REST API response messages will contain a string as an explanation. Currently, the string of explanation is translated based on server side locale. I got a new requirement: to translate REST API response messages based on the requested language from client side.

For example, if the client is in China and sends a request with a parameter "Accept-Language: zh-CN" in HTTP header, the explanation in the REST API response should be translated into Chinese. If the client is in France and sends a request with a parameter "Accept-Language: fr-FR" in header, the explanation in the REST API response should be translated into French. Regardless of the response messages translation, the log in server side will be translated based on server side locale setting.

In order to fulfil this request, I think, the most difficult thing is to separate the logic of LOG and API response. Because currently, the API response will be written to the LOG exactly as it is. (Refer to ResourceExceptionHandler.__exit__(self, ex_type, ex_value, ex_traceback) in Nova/nova/api/openstack/wsgi.py) But I need the response message in the language specified by client, and the LOG in the language specified by server locale.

I have two solutions for this requirement.

One is to maintain a map between server locale translation and client requested translation in gettextutils.py. When raising a webob.exc.HTTPException, still use the server locale translation as the explanation, which will be written to log. When composing the response JSON message (Refer to Fault.__call__(self, req) in Nova/nova/api/openstack/wsgi.py), get the client requested translation from the map and put it in the response JSON object.

The other is to remove log writing from API response logic, which means, removing the log statements in ResourceExceptionHandler.__exit__(self, ex_type, ex_value, ex_traceback) in Nova/nova/api/openstack/wsgi.py. Add explicit LOG statement before raising a webob.exc.HTTPException. For example:

msg = _('Invalid is_public filter [%s]') % req.params['is_public']
raise webob.exc.HTTPBadRequest(explanation=msg)

will be changed to:

msg = _gettext('Invalid is_public filter [%s]')
LOG.error(_(msg) % req.params['is_public'])
raise webob.exc.HTTPBadRequest(explanation=_(msg,req.get_accept_language()) % req.params['is_public'])

Method _gettext(string) will do nothing to the string, just for string extraction. Method _(msg) will be changed to accept the second parameter _(msg, locale).

Please let me know your opinion to these two solutions. Which one do you prefer? Or do you have better solutions?

Regards
Ying Chun Guo (Daisy)
China Standards and Open Source Team
Emerging Technology Institute (ETI)
IBM China Development Lab
Tel:(86-10)82453491
Email: guoyingc at cn.ibm.com<mailto:guoyingc at cn.ibm.com>
Address: 1F Tower B, Diamond Building 19 Zhongguancun Software Park,
8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/24214304/attachment.html>