Open Stack

Hi, Juergen

Thank you for your response. It's very normal that people have different
opinions.

Firstly, I would argue REST API return message is not only programmatic
error messages,
but also user (administrators, or tenants of public cloud)  facing
messages.

Typically the API return messages are the explain errors/failures.
The question is whether these messages would be shown directly to end
users.
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,
e.g."Instance does not exist" or "Instance is not a member of specified
network"
Programmers may be well educated.
But some administrators, or even tenants of the public cloud, may not feel
comfortable to English strings.
So I think, the translation of user facing messages is valuable to
OpenStack selling.
The API return messages should be translated into client specified
language,
because OpenStack server may be in US, but the access of public cloud may
be from China.

Secondly, I would say both translation and not translation have
advantages/pros and disadvantages/cons.
The thorough solution is to introduce coding system to messages, assign a
universal identifier to each message.
Thus messages can not only be searched by strings, but also searched by
identifier.
That will solve the searching issue.
Eric Windisch has a very good description of universal identifier.
If you are interested, you can read it here:
http://lists.openstack.org/pipermail/openstack-dev/2012-November/002396.html
Of course, if google can support multiple languages search, it will be
wonderful.

Daisy


"Juergen Brendel (jbrendel)" <jbrendel at cisco.com> wrote on 2012/11/16
02:44:18:

> "Juergen Brendel (jbrendel)" <jbrendel at cisco.com>
> 2012/11/16 02:44
>
> Please respond to
> OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
>
> To
>
> OpenStack Development Mailing List <openstack-dev at lists.openstack.org>,
>
> cc
>
> Subject
>
> Re: [openstack-dev] Translate REST API return message to a different
> language as log translation
>
>
> 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
> Address: 1F Tower B, Diamond Building 19 Zhongguancun Software Park,
> 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121116/dca9f122/attachment.html>