I agree that non-user visible protocol elements should not be translated. I think we need to dig more on the error messages. E.g., see: http://docs.openstack.org/api/openstack-compute/2/content/Asynchronous_Faults-d1e2009.html
The example there contains: "Could not find image 52415800-8b69-11e0-9b19-734f6f007777" Which, as is, will need translation. Should it be redesigned? Probably. All of that aside, there are other potentially user-visible aspects of the Nova API (to pick on it for a moment), including machine names and metadata. E.g., http://docs.openstack.org/api/openstack-compute/2/content/Create_or_Replace_Metadata-d1e5358.html Now, both XML and JSON support Unicode, but: * We don't have language flagging here; is it needed? (My tentative answer: maybe, but hopefully not). * If we do, do we allow multiple values for the same key, to allow it to be multilingual? (same hope as above). etc. I think I brought this up a while back, and was told that it wasn't in-scope yet. Perhaps with our growing community, that needs another look? Cheers, On 12/04/2012, at 12:33 PM, Joshua Harlow wrote: > So u have just touched on another issue, > > I would still say that exception messages should not be translated (+1), haha. > > If this is needed, then there is something wrong with the code and how > exceptions are used instead (ie the bad code smell). Exceptions should be > meant for error control flow, what they were designed for, not for user > facing messages. I think it is more common to have a layer that translates > exceptions into meaningful localized messages, but there needs to be a > separation between exceptions and there localized messages (they should not > be combined). This is a common thing afaik, its called separation of model > and view, aka, mvc, (think of the exceptions as a model/controller(?), if the > messages – the view are intertwined that seems broke). > > This is common with a lot of other parts of openstack as well, ec2 > formatting/response creation should be separated from nova logic (ec2 should > be a view, which it mostly is right now) and so on... > > On 4/12/12 4:27 AM, "Hua ZZ Zhang" <[email protected]> wrote: > > My cents: > > Apache HTTP is not so equivelant to OpenStack here. Generally it doesn't care > about the application errors or exceptions thrown by web applications. In > openstack, exceptions have been defined in nova, horizon, keystone etc. The > messages of these exceptions are important for different users to understand > what has happened. These messages always need to be localized, returned and > displayed on user interface, not just be logged in backend system. It is very > common practice for a global software project. > > Sean Dague wrote: > > If we want to think about OpenStack as a basic building block like > > Apache, i18n is critical. Otherwise there are regions that won't adopt > > it solely because of a lack of i18n. > > Note that Apache HTTPd, for instance, does not seem to internationalize > its error messages. Only the (enduser-facing) HTML pages it gives back > in response to invalid requests are. > > > > Best Regards, > > Edward Zhang(张华) > Staff Software Engineer > Travel&Transportation Standards > Emerging Technology Institute(ETI) > IBM China Software Development Lab > e-mail: [email protected] > Notes ID: Hua ZZ Zhang/China/IBM > Tel: 86-10-82450483地址:北京市海淀区东北旺西路8号 中关村软件园28号楼 环宇大厦3层 邮编：100193 > Address: 3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West > Road, Haidian District, Beijing, P.R.C.100193 > <image.gif><image.gif> > > <image.gif> > <image.gif>Thierry Carrez ---2012-04-12 16:51:59---Sean Dague wrote: > > Thierry Carrez <[email protected]> > Sent by: [email protected] 2012-04-12 > 16:47 > <image.gif> > To > > <image.gif> > [email protected] > <image.gif> > > cc > > <image.gif> > <image.gif> > > Subject > > <image.gif> > Re: [Openstack] I18n issue for OpenStack > <image.gif><image.gif> > Sean Dague wrote: > > If we want to think about OpenStack as a basic building block like > > Apache, i18n is critical. Otherwise there are regions that won't adopt > > it solely because of a lack of i18n. > > Note that Apache HTTPd, for instance, does not seem to internationalize > its error messages. Only the (enduser-facing) HTML pages it gives back > in response to invalid requests are. > > > Is there a metric on the completeness so far? Something automated that > > could be a jenkins coverage kind of test? > > Oddly enough, it's not a question of completeness of translations. > Piggybacking on the awesome Launchpad Translations community always gave > us great coverage. It's more a code support and CI integration issue. > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
