Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

I18n issue for OpenStack

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


sbhou at cn

Apr 11, 2012, 2:07 AM

Post #1 of 18 (527 views)
Permalink
I18n issue for OpenStack

Hi there from OpenStack Community,

After the research done by my colleage Edward Zhang and myself, we have
found the following issues for openstack. We have already raised bug
https://bugs.launchpad.net/nova/+bug/974810.

1. The ROOT cause that i18n did not work in Nova
In Nova, within nova.image, there is a python file glance.py. This file
has a line of code GlanceClient =
utils.import_class('glance.client.Client'),
which calls the class glance.client.Client from Glance project. Each time
this line of code is called, the gettext domain will change from nova to
glance. But it doesn't recover nova domain after glance client returns the
control. So the i18n won't be correctly working in nova.

Detailed explanation:
Within Nova.__init__.py, there is gettext.install('nova', unicode=1). If
we want to make i18n (e.g. Chinese) work,
we need to modify it into gettext.install('nova', [path of locale
directory], unicode=1). The first parameter "nova" is the domain for i18n
within nova project.
However, when the code as the right image shows is called,
gettext.install('glance', unicode=1) within glance.__init__.py will be
called. So the domain switches
from 'nova' to 'glance', though we are still running the nova project.
Nova project needs 'nova' as the domain. When the domain changes,
certainly i18n will fail.


2. Differences between the development mode and the operation mode
We are using devstack to run our environment. As we talked about changing
gettext.install('nova', unicode=1) into
gettext.install('nova', [path of locale directory], unicode=1) before,
this may lead to another issue. gettext.install has a default directory,
which is where openstack
can install its locale files, like all the .mo files. However, devstack
does not install locale files in the default directory, which is why we
need to make the change.
We suggest that openstack have two modes: development and operation.
Different modes have different settings for the paths.


3. Improvement of the context management
There is blueprint about decoupling client code of glance from the glance
project and there is a python-glaceclient under development. It can
resolve i18n issue potentially, since
nova won't call glance directly and glance domain won't be loaded in nova.
In our opinion, we would call it AVOID it rather than RESOLVE it. If we go
one step further,
this indicates that there is an issue for the context management.
OpenStack has different projects and different logging environments, etc,
which we call context.
It is natual for us to switch context b/w different program, e.g. from
nova to glance. In nova, there is no clear management and indication that
the context
has been changed or clear exist for the context to switch back. The i18n
issue is just a tip of the iceberg for the context management. It is a
potential improvement for openstack.

We hope the above information can help OpenStack become better and we
would like to hear more comments from our community.
Thank you very much.

Best wishes.
Vincent Hou (侯胜博)

Software Engineer, Standards Growth Team, Emerging Technology Institute,
IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM [at] IBMC E-mail: sbhou [at] cn
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
West Road, Haidian District, Beijing, P.R.C.100193


thierry at openstack

Apr 11, 2012, 5:41 AM

Post #2 of 18 (510 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Sheng Bo Hou wrote:
> After the research done by my colleage Edward Zhang and myself, we have
> found the following issues for openstack. We have already raised bug
> https://bugs.launchpad.net/nova/+bug/974810
> <https://bugs.launchpad.net/nova/+bug/974810> .
> [...]

Thanks for your analysis. We plan to discuss how to fix and extend I18N
at the summit. One question that was raised on the ML in February was
whether internationalization was actually worth the effort for
infrastructure software like OpenStack.

I'll be the first to admit that there are other languages than English,
but all our open development is based in English already (bugs, reviews,
commit messages, mailing-lists, IRC...), so I don't think supporting
more languages in the software itself will help growing our developer
community.

On our users community, do operators of OpenStack need translated error
messages ? Given that translations are often incomplete, is it worth it
? What do comparable infrastructure open source software projects
provide ? The effort to provide them has proven non-trivial, I'd like to
make sure it's time well spent.

Please weigh in as a lot of our international community won't be around
in San Francisco next week, and I want their voice heard :)

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


sdague at linux

Apr 11, 2012, 11:57 AM

Post #3 of 18 (516 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

On 04/11/2012 08:41 AM, Thierry Carrez wrote:
> Sheng Bo Hou wrote:
>> After the research done by my colleage Edward Zhang and myself, we have
>> found the following issues for openstack. We have already raised bug
>> https://bugs.launchpad.net/nova/+bug/974810
>> <https://bugs.launchpad.net/nova/+bug/974810> .
>> [...]
>
> Thanks for your analysis. We plan to discuss how to fix and extend I18N
> at the summit. One question that was raised on the ML in February was
> whether internationalization was actually worth the effort for
> infrastructure software like OpenStack.
>
> I'll be the first to admit that there are other languages than English,
> but all our open development is based in English already (bugs, reviews,
> commit messages, mailing-lists, IRC...), so I don't think supporting
> more languages in the software itself will help growing our developer
> community.

I would tend to disagree with that. People are more likely to invest
their time in software if they'll be able to use it better in their
locale. I think this is definitely even more true in places where
English has less of a dominant presence. It may even bring people to the
table solely interested in helping with translation. I've seen that
happen elsewhere.

> On our users community, do operators of OpenStack need translated error
> messages ? Given that translations are often incomplete, is it worth it
> ? What do comparable infrastructure open source software projects
> provide ? The effort to provide them has proven non-trivial, I'd like to
> make sure it's time well spent.

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.

Is there a metric on the completeness so far? Something automated that
could be a jenkins coverage kind of test?

-Sean

--
Sean Dague
IBM Linux Technology Center
email: sldague [at] us
alt-email: sdague [at] linux


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


harlowja at yahoo-inc

Apr 11, 2012, 12:22 PM

Post #4 of 18 (519 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

So there is a question here that I don't understand.

There a different levels of I18N, for say user facing error messages, or for other things I consider UI (horizon).

Those need to be I18N and all that. I think the larger part that I don't understand is why the things that are not the above (log messages) are being internationalized.

So what level do we want to have ;) And what level is normal for people to expect (do systems like hadoop do I18N on there error messages, do other apache projects?)

On 4/11/12 11:57 AM, "Sean Dague" <sdague [at] linux> wrote:

On 04/11/2012 08:41 AM, Thierry Carrez wrote:
> Sheng Bo Hou wrote:
>> After the research done by my colleage Edward Zhang and myself, we have
>> found the following issues for openstack. We have already raised bug
>> https://bugs.launchpad.net/nova/+bug/974810
>> <https://bugs.launchpad.net/nova/+bug/974810> .
>> [...]
>
> Thanks for your analysis. We plan to discuss how to fix and extend I18N
> at the summit. One question that was raised on the ML in February was
> whether internationalization was actually worth the effort for
> infrastructure software like OpenStack.
>
> I'll be the first to admit that there are other languages than English,
> but all our open development is based in English already (bugs, reviews,
> commit messages, mailing-lists, IRC...), so I don't think supporting
> more languages in the software itself will help growing our developer
> community.

I would tend to disagree with that. People are more likely to invest
their time in software if they'll be able to use it better in their
locale. I think this is definitely even more true in places where
English has less of a dominant presence. It may even bring people to the
table solely interested in helping with translation. I've seen that
happen elsewhere.

> On our users community, do operators of OpenStack need translated error
> messages ? Given that translations are often incomplete, is it worth it
> ? What do comparable infrastructure open source software projects
> provide ? The effort to provide them has proven non-trivial, I'd like to
> make sure it's time well spent.

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.

Is there a metric on the completeness so far? Something automated that
could be a jenkins coverage kind of test?

-Sean

--
Sean Dague
IBM Linux Technology Center
email: sldague [at] us
alt-email: sdague [at] linux


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


zhuadl at cn

Apr 11, 2012, 7:37 PM

Post #5 of 18 (516 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Agree with you. UI level i18n is most important part since it will make
Openstack easier to use. Horizon does have built-in i18n support but need
to be translated. we're planning to help on this.

Best Regards,


Edward Zhang(张华) 地址:北京市海淀区东北旺西路8号 中关村
Staff Software Engineer 软件园28号楼 环宇大厦3层 邮编:100193
Travel&Transportation Standards Address: 3F Ring, Building 28
Emerging Technology Institute(ETI) Zhongguancun Software Park, 8
IBM China Software Development Lab Dongbeiwang West Road, Haidian
e-mail: zhuadl [at] cn District, Beijing, P.R.C.100193
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483













Joshua Harlow
<harlowja [at] yahoo-
nc.com> To
Sent by: Sean Dague
openstack-bounces <sdague [at] linux>,
+zhuadl=cn.ibm.co openstack
m [at] lists <openstack [at] lists>
.net cc

Subject
2012-04-12 03:22 Re: [Openstack] I18n issue for
OpenStack










So there is a question here that I don’t understand.

There a different levels of I18N, for say user facing error messages, or
for other things I consider UI (horizon).

Those need to be I18N and all that. I think the larger part that I don’t
understand is why the things that are not the above (log messages) are
being internationalized.

So what level do we want to have ;) And what level is normal for people to
expect (do systems like hadoop do I18N on there error messages, do other
apache projects?)

On 4/11/12 11:57 AM, "Sean Dague" <sdague [at] linux> wrote:

On 04/11/2012 08:41 AM, Thierry Carrez wrote:
> Sheng Bo Hou wrote:
>> After the research done by my colleage Edward Zhang and myself, we
have
>> found the following issues for openstack. We have already raised
bug
>> https://bugs.launchpad.net/nova/+bug/974810
>> <https://bugs.launchpad.net/nova/+bug/974810> .
>> [...]
>
> Thanks for your analysis. We plan to discuss how to fix and extend
I18N
> at the summit. One question that was raised on the ML in February
was
> whether internationalization was actually worth the effort for
> infrastructure software like OpenStack.
>
> I'll be the first to admit that there are other languages than
English,
> but all our open development is based in English already (bugs,
reviews,
> commit messages, mailing-lists, IRC...), so I don't think
supporting
> more languages in the software itself will help growing our
developer
> community.

I would tend to disagree with that. People are more likely to invest
their time in software if they'll be able to use it better in their
locale. I think this is definitely even more true in places where
English has less of a dominant presence. It may even bring people to
the
table solely interested in helping with translation. I've seen that
happen elsewhere.

> On our users community, do operators of OpenStack need translated
error
> messages ? Given that translations are often incomplete, is it
worth it
> ? What do comparable infrastructure open source software projects
> provide ? The effort to provide them has proven non-trivial, I'd
like to
> make sure it's time well spent.

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.

Is there a metric on the completeness so far? Something automated
that
could be a jenkins coverage kind of test?

-Sean

--
Sean Dague
IBM Linux Technology Center
email: sldague [at] us
alt-email: sdague [at] linux


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Attachments: 2E590967.gif (1.25 KB)
  ecblank.gif (45 B)
  graycol.gif (0.10 KB)
  pic25435.gif (1.23 KB)


thierry at openstack

Apr 12, 2012, 1:47 AM

Post #6 of 18 (514 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

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.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


thierry at openstack

Apr 12, 2012, 1:52 AM

Post #7 of 18 (516 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Joshua Harlow wrote:
> So there is a question here that I don抰 understand.
>
> There a different levels of I18N, for say user facing error messages, or
> for other things I consider UI (horizon).
>
> Those need to be I18N and all that. I think the larger part that I don抰
> understand is why the things that are not the above (log messages) are
> being internationalized.
>
> So what level do we want to have ;) And what level is normal for people
> to expect (do systems like hadoop do I18N on there error messages, do
> other apache projects?)

I agree with you.

Documentation and user-facing interfaces should definitely support I18N.
That means Horizon, and (maybe) the Python client bindings.
Operators-facing log messages... not so much. By internationalizing them
we lose the ability to google for them, and I'm not convinced the
trade-off is favorable for that particular population.

If you come to the design summit and care about this, join us at the
"I18N in OpenStack" session.

Regards,

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


chrisfer at us

Apr 12, 2012, 3:52 AM

Post #8 of 18 (538 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

+1
It is important that we distinguish between those who might contribute to the development of OpenStack, who often have advancedlanguage skills, as contrasted with those who might be asked to operate a cloud based on OpenStack. While it may be that the languageof open source development is English, it is not as likely that you'll find someone in IT operations at a company in a non-English language speakingcountry who has advanced (and in some cases, any) english language skills. For them, English language log messages might as well have been written in Romulan.
As a means of making this real, imagine trying to operate and debug OpenStack if all of the log messages were written in Simple Chinese.Who amongst us could do that, or would much less even attempt it? I rest my case.
It is critically important that we localize as much as possible, including log messages, install and operations manuals as well as UI components for locales that we would like to see adopt OpenStack. Thorough globalization will be critical to broad adoption of OpenStack,especially in emerging geographies.
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chrisfer [at] us
Twitter: christo4ferris
phone: +1 508 234 2986

-----openstack-bounces+chrisfer=us.ibm.com [at] lists wrote: -----To: openstack [at] lists
From: Sean Dague
Sent by: openstack-bounces+chrisfer=us.ibm.com [at] lists
Date: 04/11/2012 03:01PM
Subject: Re: [Openstack] I18n issue for OpenStack

On 04/11/2012 08:41 AM, Thierry Carrez wrote:
> Sheng Bo Hou wrote:
>> After the research done by my colleage Edward Zhang and myself, we have
>> found the following issues for openstack. We have already raised bug
>> https://bugs.launchpad.net/nova/+bug/974810"]https://bugs.launchpad.net/nova/+bug/974810
>> <https://bugs.launchpad.net/nova/+bug/974810"]https://bugs.launchpad.net/nova/+bug/974810> .
>> [..]
>
> Thanks for your analysis. We plan to discuss how to fix and extend I18N
> at the summit. One question that was raised on the ML in February was
> whether internationalization was actually worth the effort for
> infrastructure software like OpenStack.
>
> I'll be the first to admit that there are other languages than English,
> but all our open development is based in English already (bugs, reviews,
> commit messages, mailing-lists, IRC...), so I don't think supporting
> more languages in the software itself will help growing our developer
> community.

I would tend to disagree with that. People are more likely to invest
their time in software if they'll be able to use it better in their
locale. I think this is definitely even more true in places where
English has less of a dominant presence. It may even bring people to the
table solely interested in helping with translation. I've seen that
happen elsewhere.

> On our users community, do operators of OpenStack need translated error
> messages ? Given that translations are often incomplete, is it worth it
> ? What do comparable infrastructure open source software projects
> provide ? The effort to provide them has proven non-trivial, I'd like to
> make sure it's time well spent.

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.

Is there a metric on the completeness so far? Something automated that
could be a jenkins coverage kind of test?

-Sean

--
Sean Dague
IBM Linux Technology Center
email: sldague [at] us
alt-email: sdague [at] linux


_______________________________________________
Mailing list: https://launchpad.net/~openstack"]https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack"]https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp



zhuadl at cn

Apr 12, 2012, 4:27 AM

Post #9 of 18 (516 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

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(张华) 地址:北京市海淀区东北旺西路8号 中关村
Staff Software Engineer 软件园28号楼 环宇大厦3层 邮编:100193
Travel&Transportation Standards Address: 3F Ring, Building 28
Emerging Technology Institute(ETI) Zhongguancun Software Park, 8
IBM China Software Development Lab Dongbeiwang West Road, Haidian
e-mail: zhuadl [at] cn District, Beijing, P.R.C.100193
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483













Thierry Carrez
<thierry [at] opensta
k.org> To
Sent by: openstack [at] lists
openstack-bounces cc
+zhuadl=cn.ibm.co
m [at] lists Subject
.net Re: [Openstack] I18n issue for
OpenStack

2012-04-12 16:47








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.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Attachments: 36224036.gif (1.25 KB)
  ecblank.gif (45 B)
  graycol.gif (0.10 KB)
  pic09216.gif (1.23 KB)


soren at linux2go

Apr 12, 2012, 4:43 AM

Post #10 of 18 (514 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Den 12. apr. 2012 13.27 skrev Hua ZZ Zhang <zhuadl [at] cn>:
> 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.

OpenStack isn't an interactive application. It's a piece of server
software. I'm struggling to think of any server software that writes
anything in its log files in anything other than English. I'm Danish
and generally configure my servers to speak Danish, so I should have
seen it at least occasionally. Do you have any examples of this
alleged "very common practice"?

--
Soren Hansen 聽 聽 聽 聽 聽 聽 | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer 聽 聽 聽 聽 | http://www.ubuntu.com/
OpenStack Developer 聽 聽 聽| http://www.openstack.org/

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


soren at linux2go

Apr 12, 2012, 4:50 AM

Post #11 of 18 (515 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Don't get me wrong.. I'd be happy to have the various openstack
clients offer localised error messages. I'd also encourage a
centralised effort to collect these translationns (so that all the
various language bindings will use the same localised error messages).

On the server, though, I believe we should stick to English and
perhaps have every error message include a link (e.g.
http://docs.openstack.doc/exception/NoNetworksDefinedException) to a
localised docs site. I think losing the ability to search the web for
error messages would be a major loss.

--
Soren Hansen 聽 聽 聽 聽 聽 聽 | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer 聽 聽 聽 聽 | http://www.ubuntu.com/
OpenStack Developer 聽 聽 聽| http://www.openstack.org/

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


sbhou at cn

Apr 12, 2012, 6:06 AM

Post #12 of 18 (517 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Dear OpenStack friends,

It will be happy and great for our OpenStack community to see this open
project open to more market all over the world.
In China, OpenStack community is very active. I heard many Chinese
engineers talking about their wish to have a Chinese versioned openStack,
including documentation's, manuals, user interfaces, error messages, etc
in OpenStack meet-ups.
I have many European friends and also Danish friends, since I used to do
my university there. They all spoke perfect English, which made me admire,
cos they were linguists in my point of view. Oriental languages are
different. They are "too far" from the western lingual system. In China,
there are many talented engineers, who are not that kind of "linguists",
but they are lover of open source. I think it is amazing to open the
"door" to them. In China, it is very appreciated for software to be
localized as much as possible.
I used to google or baidu(a famous Chinese search engine) error messages
and logs in Chinese for other software, though it is not Apache. I found a
lot of useful references in Chinese, because it has been localized. If it
is not localized well first, of course it does not have the google or
yahoo ability to search.:-)
So far I am rather grateful for all the messages following this i18 issue.
Thank you so much.

Best wishes.
Vincent Hou (侯胜博)

Software Engineer, Standards Growth Team, Emerging Technology Institute,
IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM [at] IBMC E-mail: sbhou [at] cn
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
West Road, Haidian District, Beijing, P.R.C.100193



Soren Hansen <soren [at] linux2go>
Sent by: openstack-bounces+sbhou=cn.ibm.com [at] lists
2012-04-12 19:50

To
Hua ZZ Zhang/China/IBM [at] IBMC
cc
openstack [at] lists, Thierry Carrez <thierry [at] openstack>,
openstack-bounces+zhuadl=cn.ibm.com [at] lists
Subject
Re: [Openstack] I18n issue for OpenStack






Don't get me wrong.. I'd be happy to have the various openstack
clients offer localised error messages. I'd also encourage a
centralised effort to collect these translationns (so that all the
various language bindings will use the same localised error messages).

On the server, though, I believe we should stick to English and
perhaps have every error message include a link (e.g.
http://docs.openstack.doc/exception/NoNetworksDefinedException) to a
localised docs site. I think losing the ability to search the web for
error messages would be a major loss.

--
Soren Hansen | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


sdague at linux

Apr 12, 2012, 6:32 AM

Post #13 of 18 (517 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

On 04/12/2012 04:52 AM, Thierry Carrez wrote:
> Joshua Harlow wrote:
>> So there is a question here that I don抰 understand.
>>
>> There a different levels of I18N, for say user facing error messages, or
>> for other things I consider UI (horizon).
>>
>> Those need to be I18N and all that. I think the larger part that I don抰
>> understand is why the things that are not the above (log messages) are
>> being internationalized.
>>
>> So what level do we want to have ;) And what level is normal for people
>> to expect (do systems like hadoop do I18N on there error messages, do
>> other apache projects?)
>
> I agree with you.
>
> Documentation and user-facing interfaces should definitely support I18N.
> That means Horizon, and (maybe) the Python client bindings.
> Operators-facing log messages... not so much. By internationalizing them
> we lose the ability to google for them, and I'm not convinced the
> trade-off is favorable for that particular population.

As long as user facing interfaces also means command line interface, I
think we're on the same page.

-Sean

--
Sean Dague
IBM Linux Technology Center
email: sldague [at] us
alt-email: sdague [at] linux


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


david.kranz at qrclab

Apr 12, 2012, 6:46 AM

Post #14 of 18 (516 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

Both points of view being expressed about this with respect to log error
messages are valid and need to be accommodated.
An answer, as was suggested a while back, is for error messages to have
two parts:

1. A locale-independent part that can be used for searches or understood
by developers who get logs as parts of bug reports.
2. A localized part that lets operators determine if the problem is
their issue or an OpenStack bug to be reported.

The current English string would serve the first role, and the logging
code could be changed to also emit the localized string if available. I
would argue
for this only in the case of ERROR messages and not DEBUG.

While on the subject of logs, it would be good to agree on what actions
should cause errors in logs to appear. Ideally, they would only occur if
an OpenStack bug
was detected (out-of-bounds array ref, etc.) or some operational problem
occurred (disk ran out of space, etc.). Right now errors are sometimes
output for other
reasons such as bad arguments to api calls. This makes it difficult for
an operator to know when a real problem with the system has occurred.

David Kranz
Quanta Research Cambridge




On 4/12/2012 9:06 AM, Sheng Bo Hou wrote:
> Dear OpenStack friends,
>
> It will be happy and great for our OpenStack community to see this
> open project open to more market all over the world.
> In China, OpenStack community is very active. I heard many Chinese
> engineers talking about their wish to have a Chinese versioned
> openStack, including documentation's, manuals, user interfaces, error
> messages, etc in OpenStack meet-ups.
> I have many European friends and also Danish friends, since I used to
> do my university there. They all spoke perfect English, which made me
> admire, cos they were linguists in my point of view. Oriental
> languages are different. They are "too far" from the western lingual
> system. In China, there are many talented engineers, who are not that
> kind of "linguists", but they are lover of open source. I think it is
> amazing to open the "door" to them. In China, it is very appreciated
> for software to be localized as much as possible.
> I used to google or baidu(a famous Chinese search engine) error
> messages and logs in Chinese for other software, though it is not
> Apache. I found a lot of useful references in Chinese, because it has
> been localized. If it is not localized well first, of course it does
> not have the google or yahoo ability to search.:-)
> So far I am rather grateful for all the messages following this i18
> issue. Thank you so much.
>
> Best wishes.
> Vincent Hou (???)
>
> Software Engineer, Standards Growth Team, Emerging Technology
> Institute, IBM China Software Development Lab
>
> Tel: 86-10-82450778 Fax: 86-10-82453660
> Notes ID: Sheng Bo Hou/China/IBM [at] IBMC E-mail: sbhou [at] cn
> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
> West Road, Haidian District, Beijing, P.R.C.100193
>
>
> *Soren Hansen <soren [at] linux2go>*
> Sent by: openstack-bounces+sbhou=cn.ibm.com [at] lists
>
> 2012-04-12 19:50
>
>
> To
> Hua ZZ Zhang/China/IBM [at] IBMC
> cc
> openstack [at] lists, Thierry Carrez
> <thierry [at] openstack>,
> openstack-bounces+zhuadl=cn.ibm.com [at] lists
> Subject
> Re: [Openstack] I18n issue for OpenStack
>
>
>
>
>
>
>
>
>
> Don't get me wrong.. I'd be happy to have the various openstack
> clients offer localised error messages. I'd also encourage a
> centralised effort to collect these translationns (so that all the
> various language bindings will use the same localised error messages).
>
> On the server, though, I believe we should stick to English and
> perhaps have every error message include a link (e.g.
> http://docs.openstack.doc/exception/NoNetworksDefinedException) to a
> localised docs site. I think losing the ability to search the web for
> error messages would be a major loss.
>
> --
> Soren Hansen | http://linux2go.dk/
> Senior Software Engineer | http://www.cisco.com/
> Ubuntu Developer | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


harlowja at yahoo-inc

Apr 12, 2012, 10:33 AM

Post #15 of 18 (521 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

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" <zhuadl [at] cn> 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: zhuadl [at] cn
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
[cid:3417071582_3128387][cid:3417071582_3146577]

[cid:3417071582_3132379]
[cid:3417071582_3124536]Thierry Carrez ---2012-04-12 16:51:59---Sean Dague wrote:


Thierry Carrez <thierry [at] openstack>
Sent by: openstack-bounces+zhuadl=cn.ibm.com [at] lists 2012-04-12 16:47

[cid:3417071582_3170778]

To

[cid:3417071582_3169928]
openstack [at] lists
[cid:3417071582_3171998]

cc

[cid:3417071582_3154088]
[cid:3417071582_3146520]

Subject

[cid:3417071582_3157167]
Re: [Openstack] I18n issue for OpenStack
[cid:3417071582_3126377][cid:3417071582_3170799]
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.
Attachments: image.gif (1.25 KB)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (0.10 KB)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (45 B)
  image.gif (45 B)


mnot at mnot

Apr 12, 2012, 4:01 PM

Post #16 of 18 (513 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

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" <zhuadl [at] cn> 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: zhuadl [at] cn
> 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 <thierry [at] openstack>
> Sent by: openstack-bounces+zhuadl=cn.ibm.com [at] lists 2012-04-12 16:47
> <image.gif>
> To
>
> <image.gif>
> openstack [at] lists
> <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 : openstack [at] lists
> 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 : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


fifieldt at unimelb

Apr 12, 2012, 4:12 PM

Post #17 of 18 (515 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

A good idea to separate into two parts, however I fear that the current
English strings don't serve the first role as well as first appears.
This has to do with the pre-processing we do on error strings to make
more accurate searches and error report titles.

A quick, very artificial example:

"Unable to get service info: Malformed request url"

As English speakers, we can look at this and see that "Unable to get
service info" is what happened, and "Malformed request url" is why.

So, knowing that there are probably many possible reasons for 'why' we
were "Unable to get service info", we might chop this part out of our
search term, or when we ask for help - and indeed you can see an example
of this in a title here:
https://answers.launchpad.net/horizon/+question/190188

In other languages sometimes the sentence order is much different. For
example, in Chinese, that error could be written something like:

鍥犱负閿欒鏍煎紡鐨勮姹俇RL鎵浠ユ棤娉曡幏寰楁湇鍔′俊鎭

As a Chinese speaker, you know what this says and you can work out the
'why' and the 'what' in your search term.

As a non-Chinese speaker, you're stuck putting the whole thing into your
search engine and hoping that no-one chopped off or changed the
structural elements of the sentence such as 鍥犱负 and 鎵浠.

So, perhaps the part that can be used for searches and bug reports
really does need to be 'locale-independent'. Complex system of
impossible to understand error numbers, anyone? ;)


Regards,


Tom

On 04/12/2012 11:46 PM, David Kranz wrote:
> Both points of view being expressed about this with respect to log error
> messages are valid and need to be accommodated.
> An answer, as was suggested a while back, is for error messages to have
> two parts:
>
> 1. A locale-independent part that can be used for searches or understood
> by developers who get logs as parts of bug reports.
> 2. A localized part that lets operators determine if the problem is
> their issue or an OpenStack bug to be reported.
>
> The current English string would serve the first role, and the logging
> code could be changed to also emit the localized string if available. I
> would argue
> for this only in the case of ERROR messages and not DEBUG.
>
> While on the subject of logs, it would be good to agree on what actions
> should cause errors in logs to appear. Ideally, they would only occur if
> an OpenStack bug
> was detected (out-of-bounds array ref, etc.) or some operational problem
> occurred (disk ran out of space, etc.). Right now errors are sometimes
> output for other
> reasons such as bad arguments to api calls. This makes it difficult for
> an operator to know when a real problem with the system has occurred.
>
> David Kranz
> Quanta Research Cambridge
>
>
>
>
> On 4/12/2012 9:06 AM, Sheng Bo Hou wrote:
>> Dear OpenStack friends,
>>
>> It will be happy and great for our OpenStack community to see this
>> open project open to more market all over the world.
>> In China, OpenStack community is very active. I heard many Chinese
>> engineers talking about their wish to have a Chinese versioned
>> openStack, including documentation's, manuals, user interfaces, error
>> messages, etc in OpenStack meet-ups.
>> I have many European friends and also Danish friends, since I used to
>> do my university there. They all spoke perfect English, which made me
>> admire, cos they were linguists in my point of view. Oriental
>> languages are different. They are "too far" from the western lingual
>> system. In China, there are many talented engineers, who are not that
>> kind of "linguists", but they are lover of open source. I think it is
>> amazing to open the "door" to them. In China, it is very appreciated
>> for software to be localized as much as possible.
>> I used to google or baidu(a famous Chinese search engine) error
>> messages and logs in Chinese for other software, though it is not
>> Apache. I found a lot of useful references in Chinese, because it has
>> been localized. If it is not localized well first, of course it does
>> not have the google or yahoo ability to search.:-)
>> So far I am rather grateful for all the messages following this i18
>> issue. Thank you so much.
>>
>> Best wishes.
>> Vincent Hou (渚儨鍗)
>>
>> Software Engineer, Standards Growth Team, Emerging Technology
>> Institute, IBM China Software Development Lab
>>
>> Tel: 86-10-82450778 Fax: 86-10-82453660
>> Notes ID: Sheng Bo Hou/China/IBM [at] IBMC E-mail: sbhou [at] cn
>> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
>> West Road, Haidian District, Beijing, P.R.C.100193
>>
>>
>> *Soren Hansen <soren [at] linux2go>*
>> Sent by: openstack-bounces+sbhou=cn.ibm.com [at] lists
>>
>> 2012-04-12 19:50
>>
>>
>> To
>> Hua ZZ Zhang/China/IBM [at] IBMC
>> cc
>> openstack [at] lists, Thierry Carrez
>> <thierry [at] openstack>,
>> openstack-bounces+zhuadl=cn.ibm.com [at] lists
>> Subject
>> Re: [Openstack] I18n issue for OpenStack
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Don't get me wrong.. I'd be happy to have the various openstack
>> clients offer localised error messages. I'd also encourage a
>> centralised effort to collect these translationns (so that all the
>> various language bindings will use the same localised error messages).
>>
>> On the server, though, I believe we should stick to English and
>> perhaps have every error message include a link (e.g.
>> http://docs.openstack.doc/exception/NoNetworksDefinedException) to a
>> localised docs site. I think losing the ability to search the web for
>> error messages would be a major loss.
>>
>> --
>> Soren Hansen | http://linux2go.dk/
>> Senior Software Engineer | http://www.cisco.com/
>> Ubuntu Developer | http://www.ubuntu.com/
>> OpenStack Developer | http://www.openstack.org/
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> <https://launchpad.net/%7Eopenstack>
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> <https://launchpad.net/%7Eopenstack>
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list:https://launchpad.net/~openstack
>> Post to :openstack [at] lists
>> Unsubscribe :https://launchpad.net/~openstack
>> More help :https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


zhuadl at cn

Apr 16, 2012, 3:13 AM

Post #18 of 18 (535 views)
Permalink
Re: I18n issue for OpenStack [In reply to]

+1

The exception is used for flow control when it happens. yes, that's right
but not completed.:-)
When you look into the current design of exceptions such as nova
exceptions, they include message content which is meaningful and useful.
Apparently, the exception is not only used for flow control, but also for
showing user why this could happen. It is not bad smell for code or
conflict with MVC design pattern, I think. Add another separate layer is
complex and not necessary. The gettext tookit allow the message to be
translated or untranslated. It depends on the user requirements on this
that we can't ignore.

nova/nova/exception.py:
...
class DecryptionFailure(NovaException):
message = _("Failed to decrypt text")


class ImagePaginationFailed(NovaException):
message = _("Failed to paginate through images from image service")


class VirtualInterfaceCreateException(NovaException):
message = _("Virtual Interface creation failed")


class VirtualInterfaceMacAddressException(NovaException):
message = _("5 attempts to create virtual interface"
"with unique mac address failed")


class GlanceConnectionFailed(NovaException):
message = _("Connection to glance failed") + ": %(reason)s"


class MelangeConnectionFailed(NovaException):
message = _("Connection to melange failed") + ": %(reason)s"
...



Best Regards,


Edward Zhang(张华) 地址:北京市海淀区东北旺西路8号 中关村
Staff Software Engineer 软件园28号楼 环宇大厦3层 邮编:100193
Travel&Transportation Standards Address: 3F Ring, Building 28
Emerging Technology Institute(ETI) Zhongguancun Software Park, 8
IBM China Software Development Lab Dongbeiwang West Road, Haidian
e-mail: zhuadl [at] cn District, Beijing, P.R.C.100193
Notes ID: Hua ZZ Zhang/China/IBM
Tel: 86-10-82450483













Joshua Harlow
<harlowja [at] yahoo-
nc.com> To
Hua ZZ Zhang/China/IBM [at] IBMC,
2012-04-13 01:33 Thierry Carrez
<thierry [at] openstack>
cc
"openstack-bounces
+zhuadl=cn.ibm.com [at] lists
net" <openstack-bounces
+zhuadl=cn.ibm.com [at] lists
<openstack [at] lists>
Subject
Re: [Openstack] I18n issue for
OpenStack










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" <zhuadl [at] cn> 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: zhuadl [at] cn
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



Thierry Carrez ---2012-04-12 16:51:59---Sean Dague wrote:

Thierry Carrez <thierry [at] openstack>
Sent by: openstack-bounces
+zhuadl=cn.ibm.com [at] lists
2012-04-12 16:47



To



openstack [at] lists



cc






Subject



Re: [Openstack] I18n issue for OpenStack

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.
Attachments: 33817450.gif (1.25 KB)
  ecblank.gif (45 B)
  graycol.gif (0.10 KB)
  pic15417.gif (1.23 KB)

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.