Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/21/2017 01:06 PM, Matt Riedemann wrote:
> On 3/21/2017 2:25 AM, Akihiro Motoki wrote:
>>
>> Yes, all logging markers including LOG.exception(_LE(...)) will be
>> clean up.
>> Only user visible messages through API messages should be marked as
>> translatable.
>>
> 
> Do we still use _LE() or just _() for marking API error messages for
> translation?
> 

All of _L* no longer have any message backings, so using them just means
it's not translated at all. _() is the thing you have to use.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Matt Riedemann]

On 3/21/2017 2:25 AM, Akihiro Motoki wrote:


Yes, all logging markers including LOG.exception(_LE(...)) will be clean up.
Only user visible messages through API messages should be marked as
translatable.



Do we still use _LE() or just _() for marking API error messages for 
translation?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Akihiro Motoki]

2017-03-17 5:50 GMT+09:00 Ihar Hrachyshka :
> On Thu, Mar 16, 2017 at 12:00 PM, Doug Hellmann  wrote:
>> Please keep translations for exceptions and other user-facing messages,
>> for now.
>
> To clarify, that means LOG.exception(_LE(...)) should also be cleaned
> up? The only things that we should leave are messages that eventually
> get to users (by means of stdout for clients, or thru API payload, for
> services).

Yes, all logging markers including LOG.exception(_LE(...)) will be clean up.
Only user visible messages through API messages should be marked as
translatable.

>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

> On Mar 16, 2017, at 5:00 PM, Matt Riedemann  wrote:
> 
> On 3/16/2017 2:00 PM, Doug Hellmann wrote:
>> 
>> Based on the feedback on that list, there seems to be no real support
>> for maintaining the ability to translate log messages. I therefore
>> recommend that teams accept the patches to remove them, and stop
>> enforcing their use. Whether or not teams want to make a concerted
>> effort to sweep through the code and delete them is up to them.
>> 
>> Please keep translations for exceptions and other user-facing messages,
>> for now.
>> 
>> As Sean pointed out elsewhere, we can deal with other log-related
>> changes independently, since those are likely to need more thought to
>> write and review.
>> 
>> Doug
> 
> I would suggest someone put some notes in the oslo.i18n docs to convey the 
> message that those instructions are no longer relevant:
> 
> https://docs.openstack.org/developer/oslo.i18n/guidelines.html#log-translation

Done: https://review.openstack.org/446762


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Matt Riedemann]

On 3/16/2017 2:00 PM, Doug Hellmann wrote:


Based on the feedback on that list, there seems to be no real support
for maintaining the ability to translate log messages. I therefore
recommend that teams accept the patches to remove them, and stop
enforcing their use. Whether or not teams want to make a concerted
effort to sweep through the code and delete them is up to them.

Please keep translations for exceptions and other user-facing messages,
for now.

As Sean pointed out elsewhere, we can deal with other log-related
changes independently, since those are likely to need more thought to
write and review.

Doug


I would suggest someone put some notes in the oslo.i18n docs to convey 
the message that those instructions are no longer relevant:


https://docs.openstack.org/developer/oslo.i18n/guidelines.html#log-translation

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ihar Hrachyshka]

On Thu, Mar 16, 2017 at 12:00 PM, Doug Hellmann  wrote:
> Please keep translations for exceptions and other user-facing messages,
> for now.

To clarify, that means LOG.exception(_LE(...)) should also be cleaned
up? The only things that we should leave are messages that eventually
get to users (by means of stdout for clients, or thru API payload, for
services).

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/16/2017 03:00 PM, Doug Hellmann wrote:
> Excerpts from Doug Hellmann's message of 2017-03-10 09:39:29 -0500:
>> Excerpts from Doug Hellmann's message of 2017-03-10 09:28:52 -0500:
>>> Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:
 Doug Hellmann wrote on 3/9/2017 9:24 PM:
> Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
>> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
>>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
 On 2017-03-06 14:03, Sean Dague  wrote:
> I'm trying to understand the implications of
> https://review.openstack.org/#/c/439500. And the comment in the linked
> email:
>
> ">> Yes, we decided some time ago to not translate the log files 
> anymore and
>>> thus our tools do not handle them anymore - and in general, we 
>>> remove
>>> these kind of files."
> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> fully removed? Nova currently enforces those things are there -
> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> and want to make sure our tools aren't making us do work that the i18n
> team is ignoring and throwing away.
>> So... just looking for a definitive statement on this since there has
>> been some back and forth discussion.
>>
>> Is it correct to say - all projects may (should?) now remove all bits in
>> place for using and enforcing the _Lx() translation markers. Only _()
>> should be used for user visible error messages.
>>
>> Sean (smcginnis)
>>
> The situation is still not quite clear to me, and it would be
> unfortunate to undo too much of the translation support work because
> it will be hard to redo it.
>
> Is there documentation somewhere describing what the i18n team has
> committed to trying to translate?

 I18n team describes translation plan and priority in Zanata - 
 translation platform
   : https://translate.openstack.org/ .

>   I think I heard that there was a
> shift in emphasis to "user interfaces", but I'm not sure if that
> includes error messages in services. Should we remove all use of
> oslo.i18n from services? Or only when dealing with logs?

 When I18n team decided to removal of log translations in Barcelona last 
 October, there had been no
 discussion on the removal of oslo.i18n translation support for log 
 messages.
 (I have kept track of what I18n team discussed during Barcelona I18n 
 meetup on Etherpad - [1])

 Now I think that the final decision of oslo.i18n log translation support 
 needs more involvement
 with translators considering oslo.i18n translation support, and also 
 more people on community wide including
 project working groups, user committee, and operators as Matt suggested.

 If translating log messages is meaningful to some community members and 
 some translators show interests
 on translating log messages, then I18n team can revert the policy with 
 rolling back of translations.
 Translated strings are still alive in not only previous stable branches, 
 but also in translation memory in Zanata - translation platform.

 I would like to find some ways to discuss this topic with more community 
 wide.
>>>
>>> I would suggest that we discuss this at the Forum in Boston, but I think
>>> we need to gather some input before then because if there is a consensus
>>> that log translations are not useful we can allow the code cleanup to
>>> occur and not take up face-to-face time.
>>
>> I've started a thread on the operators mailing list [1].
>>
>> Doug
>>
>> [1] 
>> http://lists.openstack.org/pipermail/openstack-operators/2017-March/012887.html
>>
> 
> Based on the feedback on that list, there seems to be no real support
> for maintaining the ability to translate log messages. I therefore
> recommend that teams accept the patches to remove them, and stop
> enforcing their use. Whether or not teams want to make a concerted
> effort to sweep through the code and delete them is up to them.
> 
> Please keep translations for exceptions and other user-facing messages,
> for now.
> 
> As Sean pointed out elsewhere, we can deal with other log-related
> changes independently, since those are likely to need more thought to
> write and review.

ACK. Just landed the stop enforcing patch in Nova -
https://review.openstack.org/#/c/446452/

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-03-10 09:39:29 -0500:
> Excerpts from Doug Hellmann's message of 2017-03-10 09:28:52 -0500:
> > Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:
> > > Doug Hellmann wrote on 3/9/2017 9:24 PM:
> > > > Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
> > > >> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> > > >>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > >  On 2017-03-06 14:03, Sean Dague  wrote:
> > > > I'm trying to understand the implications of
> > > > https://review.openstack.org/#/c/439500. And the comment in the 
> > > > linked
> > > > email:
> > > >
> > > > ">> Yes, we decided some time ago to not translate the log files 
> > > > anymore and
> > > >>> thus our tools do not handle them anymore - and in general, we 
> > > >>> remove
> > > >>> these kind of files."
> > > > Does that mean that all the _LE, _LI, _LW stuff in projects should 
> > > > be
> > > > fully removed? Nova currently enforces those things are there -
> > > > https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> > > > and want to make sure our tools aren't making us do work that the 
> > > > i18n
> > > > team is ignoring and throwing away.
> > > >> So... just looking for a definitive statement on this since there has
> > > >> been some back and forth discussion.
> > > >>
> > > >> Is it correct to say - all projects may (should?) now remove all bits 
> > > >> in
> > > >> place for using and enforcing the _Lx() translation markers. Only _()
> > > >> should be used for user visible error messages.
> > > >>
> > > >> Sean (smcginnis)
> > > >>
> > > > The situation is still not quite clear to me, and it would be
> > > > unfortunate to undo too much of the translation support work because
> > > > it will be hard to redo it.
> > > >
> > > > Is there documentation somewhere describing what the i18n team has
> > > > committed to trying to translate?
> > > 
> > > I18n team describes translation plan and priority in Zanata - 
> > > translation platform
> > >   : https://translate.openstack.org/ .
> > > 
> > > >   I think I heard that there was a
> > > > shift in emphasis to "user interfaces", but I'm not sure if that
> > > > includes error messages in services. Should we remove all use of
> > > > oslo.i18n from services? Or only when dealing with logs?
> > > 
> > > When I18n team decided to removal of log translations in Barcelona last 
> > > October, there had been no
> > > discussion on the removal of oslo.i18n translation support for log 
> > > messages.
> > > (I have kept track of what I18n team discussed during Barcelona I18n 
> > > meetup on Etherpad - [1])
> > > 
> > > Now I think that the final decision of oslo.i18n log translation support 
> > > needs more involvement
> > > with translators considering oslo.i18n translation support, and also 
> > > more people on community wide including
> > > project working groups, user committee, and operators as Matt suggested.
> > > 
> > > If translating log messages is meaningful to some community members and 
> > > some translators show interests
> > > on translating log messages, then I18n team can revert the policy with 
> > > rolling back of translations.
> > > Translated strings are still alive in not only previous stable branches, 
> > > but also in translation memory in Zanata - translation platform.
> > > 
> > > I would like to find some ways to discuss this topic with more community 
> > > wide.
> > 
> > I would suggest that we discuss this at the Forum in Boston, but I think
> > we need to gather some input before then because if there is a consensus
> > that log translations are not useful we can allow the code cleanup to
> > occur and not take up face-to-face time.
> 
> I've started a thread on the operators mailing list [1].
> 
> Doug
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-operators/2017-March/012887.html
> 

Based on the feedback on that list, there seems to be no real support
for maintaining the ability to translate log messages. I therefore
recommend that teams accept the patches to remove them, and stop
enforcing their use. Whether or not teams want to make a concerted
effort to sweep through the code and delete them is up to them.

Please keep translations for exceptions and other user-facing messages,
for now.

As Sean pointed out elsewhere, we can deal with other log-related
changes independently, since those are likely to need more thought to
write and review.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/16/2017 05:12 AM, Rochelle Grober wrote:
> Sorry for top posting, but this is likely the best place...
> 
> I wanted to provide an update from the Ops midcycle about related topics 
> around this. 
> 
> The operators here are in general agreement that translation is not needed, 
> but they are also very interested in the possibility of getting some of their 
> long time wish list items for traceability and specificity into the log 
> messages at the same time as the translation bits are removed.  There is an 
> effort and a team of devops working on defining more specifically exactly 
> what the operators want in the messages and providing personpower to do a 
> good chunk of the work.
> 
> We hope to have some solid proposals written up for the forum so as to be 
> able to move forward and partner with the project developers on this.
> We expect two proposals, one for error codes (yes, that again, but operators 
> really want/need this) and traceability around request-ids.

Just to be clear, the delete of the existing markup is going to be
completely independent of of any markup. Deleting the i18n wrappers is
super mechanical, and can go under very fast and bulk review.

Guidelines for better tracing are great, work to contribute that in even
better, but that's something that's a lot more work, and different work.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Rochelle Grober]

Sorry for top posting, but this is likely the best place...

I wanted to provide an update from the Ops midcycle about related topics around 
this. 

The operators here are in general agreement that translation is not needed, but 
they are also very interested in the possibility of getting some of their long 
time wish list items for traceability and specificity into the log messages at 
the same time as the translation bits are removed.  There is an effort and a 
team of devops working on defining more specifically exactly what the operators 
want in the messages and providing personpower to do a good chunk of the work.

We hope to have some solid proposals written up for the forum so as to be able 
to move forward and partner with the project developers on this.
We expect two proposals, one for error codes (yes, that again, but operators 
really want/need this) and traceability around request-ids.

--Rocky

-Original Message-
From: Ian Y. Choi [mailto:ianyrc...@gmail.com] 
Sent: Wednesday, March 15, 2017 11:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [i18n] [nova] understanding log domain change - 
https://review.openstack.org/#/c/439500

Doug Hellmann wrote on 3/10/2017 11:39 PM:
> Excerpts from Doug Hellmann's message of 2017-03-10 09:28:52 -0500:
>> Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:
>>> Doug Hellmann wrote on 3/9/2017 9:24 PM:
>>>> Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
>>>>> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
>>>>>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
>>>>>>> On 2017-03-06 14:03, Sean Dague  wrote:
>>>>>>>> I'm trying to understand the implications of 
>>>>>>>> https://review.openstack.org/#/c/439500. And the comment in the 
>>>>>>>> linked
>>>>>>>> email:
>>>>>>>>
>>>>>>>> ">> Yes, we decided some time ago to not translate the log 
>>>>>>>> files anymore and
>>>>>>>>>> thus our tools do not handle them anymore - and in general, 
>>>>>>>>>> we remove these kind of files."
>>>>>>>> Does that mean that all the _LE, _LI, _LW stuff in projects 
>>>>>>>> should be fully removed? Nova currently enforces those things 
>>>>>>>> are there -
>>>>>>>> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae34
>>>>>>>> 94597e295add9cfe/nova/hacking/checks.py#L314-L333
>>>>>>>> and want to make sure our tools aren't making us do work that 
>>>>>>>> the i18n team is ignoring and throwing away.
>>>>> So... just looking for a definitive statement on this since there 
>>>>> has been some back and forth discussion.
>>>>>
>>>>> Is it correct to say - all projects may (should?) now remove all 
>>>>> bits in place for using and enforcing the _Lx() translation 
>>>>> markers. Only _() should be used for user visible error messages.
>>>>>
>>>>> Sean (smcginnis)
>>>>>
>>>> The situation is still not quite clear to me, and it would be 
>>>> unfortunate to undo too much of the translation support work 
>>>> because it will be hard to redo it.
>>>>
>>>> Is there documentation somewhere describing what the i18n team has 
>>>> committed to trying to translate?
>>> I18n team describes translation plan and priority in Zanata - 
>>> translation platform
>>>: https://translate.openstack.org/ .
>>>
>>>>I think I heard that there was a shift in emphasis to "user 
>>>> interfaces", but I'm not sure if that includes error messages in 
>>>> services. Should we remove all use of oslo.i18n from services? Or 
>>>> only when dealing with logs?
>>> When I18n team decided to removal of log translations in Barcelona 
>>> last October, there had been no discussion on the removal of 
>>> oslo.i18n translation support for log messages.
>>> (I have kept track of what I18n team discussed during Barcelona I18n 
>>> meetup on Etherpad - [1])
>>>
>>> Now I think that the final decision of oslo.i18n log translation 
>>> support needs more involvement with translators considering 
>>> oslo.i18n translation support, and also more people on community 
>>> wide including pr

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/10/2017 11:39 PM:

Excerpts from Doug Hellmann's message of 2017-03-10 09:28:52 -0500:

Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:

Doug Hellmann wrote on 3/9/2017 9:24 PM:

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate?

I18n team describes translation plan and priority in Zanata -
translation platform
   : https://translate.openstack.org/ .


   I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?

When I18n team decided to removal of log translations in Barcelona last
October, there had been no
discussion on the removal of oslo.i18n translation support for log messages.
(I have kept track of what I18n team discussed during Barcelona I18n
meetup on Etherpad - [1])

Now I think that the final decision of oslo.i18n log translation support
needs more involvement
with translators considering oslo.i18n translation support, and also
more people on community wide including
project working groups, user committee, and operators as Matt suggested.

If translating log messages is meaningful to some community members and
some translators show interests
on translating log messages, then I18n team can revert the policy with
rolling back of translations.
Translated strings are still alive in not only previous stable branches,
but also in translation memory in Zanata - translation platform.

I would like to find some ways to discuss this topic with more community
wide.

I would suggest that we discuss this at the Forum in Boston, but I think
we need to gather some input before then because if there is a consensus
that log translations are not useful we can allow the code cleanup to
occur and not take up face-to-face time.

I've started a thread on the operators mailing list [1].


Thanks a lot, Doug!

I do not know how to reply to [1] as an un-subscriber of 
openstack-operator mailing list using my Mail client program,
but since there is no response from APAC for several days [2], I asked 
Japanese & Chinese language coordinators and community leader /

ambassador to collect and tell opinions on [2].

I am now receiving opinions from Korean users & operators and currently 
there are about 10 comments all mentioning

that log translation functionality is not needed.

I will keep update if I receive more opinion on this issue.


With many thanks,

/Ian

[2] 
http://lists.openstack.org/pipermail/openstack-operators/2017-March/012902.html



Doug

[1] 
http://lists.openstack.org/pipermail/openstack-operators/2017-March/012887.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-03-10 09:28:52 -0500:
> Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:
> > Doug Hellmann wrote on 3/9/2017 9:24 PM:
> > > Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
> > >> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> > >>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> >  On 2017-03-06 14:03, Sean Dague  wrote:
> > > I'm trying to understand the implications of
> > > https://review.openstack.org/#/c/439500. And the comment in the linked
> > > email:
> > >
> > > ">> Yes, we decided some time ago to not translate the log files 
> > > anymore and
> > >>> thus our tools do not handle them anymore - and in general, we 
> > >>> remove
> > >>> these kind of files."
> > > Does that mean that all the _LE, _LI, _LW stuff in projects should be
> > > fully removed? Nova currently enforces those things are there -
> > > https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> > > and want to make sure our tools aren't making us do work that the i18n
> > > team is ignoring and throwing away.
> > >> So... just looking for a definitive statement on this since there has
> > >> been some back and forth discussion.
> > >>
> > >> Is it correct to say - all projects may (should?) now remove all bits in
> > >> place for using and enforcing the _Lx() translation markers. Only _()
> > >> should be used for user visible error messages.
> > >>
> > >> Sean (smcginnis)
> > >>
> > > The situation is still not quite clear to me, and it would be
> > > unfortunate to undo too much of the translation support work because
> > > it will be hard to redo it.
> > >
> > > Is there documentation somewhere describing what the i18n team has
> > > committed to trying to translate?
> > 
> > I18n team describes translation plan and priority in Zanata - 
> > translation platform
> >   : https://translate.openstack.org/ .
> > 
> > >   I think I heard that there was a
> > > shift in emphasis to "user interfaces", but I'm not sure if that
> > > includes error messages in services. Should we remove all use of
> > > oslo.i18n from services? Or only when dealing with logs?
> > 
> > When I18n team decided to removal of log translations in Barcelona last 
> > October, there had been no
> > discussion on the removal of oslo.i18n translation support for log messages.
> > (I have kept track of what I18n team discussed during Barcelona I18n 
> > meetup on Etherpad - [1])
> > 
> > Now I think that the final decision of oslo.i18n log translation support 
> > needs more involvement
> > with translators considering oslo.i18n translation support, and also 
> > more people on community wide including
> > project working groups, user committee, and operators as Matt suggested.
> > 
> > If translating log messages is meaningful to some community members and 
> > some translators show interests
> > on translating log messages, then I18n team can revert the policy with 
> > rolling back of translations.
> > Translated strings are still alive in not only previous stable branches, 
> > but also in translation memory in Zanata - translation platform.
> > 
> > I would like to find some ways to discuss this topic with more community 
> > wide.
> 
> I would suggest that we discuss this at the Forum in Boston, but I think
> we need to gather some input before then because if there is a consensus
> that log translations are not useful we can allow the code cleanup to
> occur and not take up face-to-face time.

I've started a thread on the operators mailing list [1].

Doug

[1] 
http://lists.openstack.org/pipermail/openstack-operators/2017-March/012887.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:
> Doug Hellmann wrote on 3/9/2017 9:24 PM:
> > Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
> >> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> >>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
>  On 2017-03-06 14:03, Sean Dague  wrote:
> > I'm trying to understand the implications of
> > https://review.openstack.org/#/c/439500. And the comment in the linked
> > email:
> >
> > ">> Yes, we decided some time ago to not translate the log files 
> > anymore and
> >>> thus our tools do not handle them anymore - and in general, we remove
> >>> these kind of files."
> > Does that mean that all the _LE, _LI, _LW stuff in projects should be
> > fully removed? Nova currently enforces those things are there -
> > https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> > and want to make sure our tools aren't making us do work that the i18n
> > team is ignoring and throwing away.
> >> So... just looking for a definitive statement on this since there has
> >> been some back and forth discussion.
> >>
> >> Is it correct to say - all projects may (should?) now remove all bits in
> >> place for using and enforcing the _Lx() translation markers. Only _()
> >> should be used for user visible error messages.
> >>
> >> Sean (smcginnis)
> >>
> > The situation is still not quite clear to me, and it would be
> > unfortunate to undo too much of the translation support work because
> > it will be hard to redo it.
> >
> > Is there documentation somewhere describing what the i18n team has
> > committed to trying to translate?
> 
> I18n team describes translation plan and priority in Zanata - 
> translation platform
>   : https://translate.openstack.org/ .
> 
> >   I think I heard that there was a
> > shift in emphasis to "user interfaces", but I'm not sure if that
> > includes error messages in services. Should we remove all use of
> > oslo.i18n from services? Or only when dealing with logs?
> 
> When I18n team decided to removal of log translations in Barcelona last 
> October, there had been no
> discussion on the removal of oslo.i18n translation support for log messages.
> (I have kept track of what I18n team discussed during Barcelona I18n 
> meetup on Etherpad - [1])
> 
> Now I think that the final decision of oslo.i18n log translation support 
> needs more involvement
> with translators considering oslo.i18n translation support, and also 
> more people on community wide including
> project working groups, user committee, and operators as Matt suggested.
> 
> If translating log messages is meaningful to some community members and 
> some translators show interests
> on translating log messages, then I18n team can revert the policy with 
> rolling back of translations.
> Translated strings are still alive in not only previous stable branches, 
> but also in translation memory in Zanata - translation platform.
> 
> I would like to find some ways to discuss this topic with more community 
> wide.

I would suggest that we discuss this at the Forum in Boston, but I think
we need to gather some input before then because if there is a consensus
that log translations are not useful we can allow the code cleanup to
occur and not take up face-to-face time.

Doug

> 
> 
> With many thanks,
> 
> /Ian
> 
> [1] https://etherpad.openstack.org/p/barcelona-i18n-meetup
> 
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/9/2017 9:24 PM:

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate?


I18n team describes translation plan and priority in Zanata - 
translation platform

 : https://translate.openstack.org/ .


  I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?


When I18n team decided to removal of log translations in Barcelona last 
October, there had been no

discussion on the removal of oslo.i18n translation support for log messages.
(I have kept track of what I18n team discussed during Barcelona I18n 
meetup on Etherpad - [1])


Now I think that the final decision of oslo.i18n log translation support 
needs more involvement
with translators considering oslo.i18n translation support, and also 
more people on community wide including

project working groups, user committee, and operators as Matt suggested.

If translating log messages is meaningful to some community members and 
some translators show interests
on translating log messages, then I18n team can revert the policy with 
rolling back of translations.
Translated strings are still alive in not only previous stable branches, 
but also in translation memory in Zanata - translation platform.


I would like to find some ways to discuss this topic with more community 
wide.



With many thanks,

/Ian

[1] https://etherpad.openstack.org/p/barcelona-i18n-meetup



Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> > On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > > On 2017-03-06 14:03, Sean Dague  wrote:
> > >> I'm trying to understand the implications of
> > >> https://review.openstack.org/#/c/439500. And the comment in the linked
> > >> email:
> > >>
> > >> ">> Yes, we decided some time ago to not translate the log files anymore 
> > >> and
> >  thus our tools do not handle them anymore - and in general, we remove
> >  these kind of files."
> > >>
> > >> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> > >> fully removed? Nova currently enforces those things are there -
> > >> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> > >> and want to make sure our tools aren't making us do work that the i18n
> > >> team is ignoring and throwing away.
> > > 
> 
> So... just looking for a definitive statement on this since there has
> been some back and forth discussion.
> 
> Is it correct to say - all projects may (should?) now remove all bits in
> place for using and enforcing the _Lx() translation markers. Only _()
> should be used for user visible error messages.
> 
> Sean (smcginnis)
> 

The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate? I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean McGinnis]

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > On 2017-03-06 14:03, Sean Dague  wrote:
> >> I'm trying to understand the implications of
> >> https://review.openstack.org/#/c/439500. And the comment in the linked
> >> email:
> >>
> >> ">> Yes, we decided some time ago to not translate the log files anymore 
> >> and
>  thus our tools do not handle them anymore - and in general, we remove
>  these kind of files."
> >>
> >> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> >> fully removed? Nova currently enforces those things are there -
> >> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> >> and want to make sure our tools aren't making us do work that the i18n
> >> team is ignoring and throwing away.
> > 

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2017-03-06 11:37:06 -0600:
> On 3/6/2017 10:28 AM, Ian Y. Choi wrote:
> >
> > +1 and for such discussions including openstack-i...@lists.openstack.org
> > mailing list would be also nice :)
> >
> > On Barcelona Design Summit, there were I18n contributor meetup and I18n
> > team members discussed a lot.
> > One of things was not to translate log-level strings for server projects.
> >
> > Note that such decision was made not because translator time is limited.
> >
> > Log messages are important to better identify which errors are being
> > posed and most operators (+ developers)
> > diagnose and start to solve error situations from the log messages.
> > I18n team previously translated log messages a lot especially thanks to
> > translation contribution from IBM. (AFAIK)
> 
>  From what I remember working on an openstack-based product at IBM years 
> ago, non-debug messages required translation. That wasn't an openstack 
> requirement, that was an IBM product requirement. And way back when the 
> IBM products had their own plumbing for i18n and did our own 
> translations, and the upstream team of developers pushed and pushed on 
> the translation teams to upstream that work to the community which they 
> eventually did. Now it sounds like the push from IBM for that work has 
> dropped off so no one is really maintaining it.

This matches my memory of the origin of the feature in oslo.i18n to
support log translations.

> > However, after then, there have been some voices - why I18n team
> > translated log messages?
> > After listening to the voices in details, I18n team identified that the
> > background of such voices was related with searching log messages on
> > Internet.
> > Searching English log messages on the Internet will retrieve more number
> > of results than searching translated log messages on the Internet.

This was, perhaps not surprisingly, the primary argument against
implementing log translations originally. As a counter argument,
we actually enabled oslo.log to write to multiple log files, using
a different language for each one. I'm not sure if any of the log
translation work was ever deployed in production, so I have no idea if
anyone took advantage of this aspect of the system.

> > Translating log messages now has two different point of views:
> >  - Will be useful for OpenStack users to better understand log messages
> > in details with translated log messages?
> >  - Or will not be useful for OpenStack users because the original log
> > messages will have better chance to find solutions who occurred the
> > similar cases on the Internet?
> 
> Another IBM-specific product thing is non-debug translated messages get 
> a unique code which isn't translated. So the message is translated, but 
> the code isn't, and the code is what you use to lookup the error on the 
> internet. There was a proposal to do this in openstack many years ago 
> but it never happened.

I've been involved in a bunch of the discussions about log and error
message codes, and so far I haven't seen a proposal that included
a system for allocating unique codes that would scale to a distributed
project like OpenStack. All of them either relied on a central registry
of IDs or on an allocation scheme that didn't take into account the
number of projects we had at the time.

If we do come up with a workable system, I would be reluctant to
go through the effort of implementing it and rolling it out if there
is not wide-spread interest in maintaining the uniqueness of those
log message IDs and ensuring they are useful. Otherwise I expect
we'll end up having a similar conversation to this one.

In Atlanta at the PTG, Eddie Ramirez showed off some work he is
doing to build a reference site based on all of the exception classes
discoverable by scanning OpenStack application code. It's not
complete, but it shows good promise. One especially nice feature
is that it would give us a single well-known URL for each exception
class that we could (a) include in the logs automatically and (b)
extend with helpful information.

> > I18n team discussed with such point of views and on Barcelona Summit the
> > latter point would be more important than the former point.
> > Also, it would be just a point of view from PTL, but it is difficult for
> > me to encourage to contribution translations which have such kind of
> > controversy.
> >
> > Now I would like to listen again to not only developers, but also
> > operators and translators - for log string translation.
> > If someone thinks that the former point would be more important than the
> > latter point, please share through this mailing list to reconsider the
> > current decision.
> >
> >
> > With many thanks,
> >
> > /Ian
> >
> 
> I'm just trying to provide some context. I don't much care about this 
> either way, but it would probably also be good to get input from the 
> product work group, user committee and operators to make sure everyone 

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Matt Riedemann]

On 3/6/2017 10:28 AM, Ian Y. Choi wrote:


+1 and for such discussions including openstack-i...@lists.openstack.org
mailing list would be also nice :)

On Barcelona Design Summit, there were I18n contributor meetup and I18n
team members discussed a lot.
One of things was not to translate log-level strings for server projects.

Note that such decision was made not because translator time is limited.

Log messages are important to better identify which errors are being
posed and most operators (+ developers)
diagnose and start to solve error situations from the log messages.
I18n team previously translated log messages a lot especially thanks to
translation contribution from IBM. (AFAIK)


From what I remember working on an openstack-based product at IBM years 
ago, non-debug messages required translation. That wasn't an openstack 
requirement, that was an IBM product requirement. And way back when the 
IBM products had their own plumbing for i18n and did our own 
translations, and the upstream team of developers pushed and pushed on 
the translation teams to upstream that work to the community which they 
eventually did. Now it sounds like the push from IBM for that work has 
dropped off so no one is really maintaining it.



However, after then, there have been some voices - why I18n team
translated log messages?
After listening to the voices in details, I18n team identified that the
background of such voices was related with searching log messages on
Internet.
Searching English log messages on the Internet will retrieve more number
of results than searching translated log messages on the Internet.

Translating log messages now has two different point of views:
 - Will be useful for OpenStack users to better understand log messages
in details with translated log messages?
 - Or will not be useful for OpenStack users because the original log
messages will have better chance to find solutions who occurred the
similar cases on the Internet?


Another IBM-specific product thing is non-debug translated messages get 
a unique code which isn't translated. So the message is translated, but 
the code isn't, and the code is what you use to lookup the error on the 
internet. There was a proposal to do this in openstack many years ago 
but it never happened.




I18n team discussed with such point of views and on Barcelona Summit the
latter point would be more important than the former point.
Also, it would be just a point of view from PTL, but it is difficult for
me to encourage to contribution translations which have such kind of
controversy.

Now I would like to listen again to not only developers, but also
operators and translators - for log string translation.
If someone thinks that the former point would be more important than the
latter point, please share through this mailing list to reconsider the
current decision.


With many thanks,

/Ian



I'm just trying to provide some context. I don't much care about this 
either way, but it would probably also be good to get input from the 
product work group, user committee and operators to make sure everyone 
is aware of the fact that service logs are no longer translated; this 
was news to me when we were releasing Ocata actually and I was waiting 
for translations for ocata RC2.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/06/2017 12:16 PM, Ihar Hrachyshka wrote:
> I have a question: why can't operators just switch to en_US to execute 
> services?
> 
> Another question: what makes log messages so much different from API
> responses? Couldn't you make the same argument that it's easier to
> find a reason for a request failure if the error message is in
> English? Should we then just stop translating any messages and say
> English is the only OpenStack language we recommend?
> 
> I try to see what makes logs so much different from API error
> messages, and why operators cannot pick the right language based on
> their priorities.

I think what I have gathered from the conversation here, and some on IRC
is that the i18n team did some reflection in Barcelona, and found that
the value of providing these translations for log messages was low
enough that they stopped wanting to commit to them.

They removed all that from their system, and pushed deletes to projects
(here is the Nova one I merged - https://review.openstack.org/#/c/439925/).

Without upstream support of these catalogs (and content in the .po
files), there is no reason for projects to have all this plumbing.

It causes quite a bit of confusion to new folks, and trips up lots of
people making changes when they forget about it (and hacking fails them).

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ihar Hrachyshka]

I have a question: why can't operators just switch to en_US to execute services?

Another question: what makes log messages so much different from API
responses? Couldn't you make the same argument that it's easier to
find a reason for a request failure if the error message is in
English? Should we then just stop translating any messages and say
English is the only OpenStack language we recommend?

I try to see what makes logs so much different from API error
messages, and why operators cannot pick the right language based on
their priorities.

On Mon, Mar 6, 2017 at 8:28 AM, Ian Y. Choi  wrote:
> Doug Hellmann wrote on 3/7/2017 12:53 AM:
>>
>> Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:
>>>
>>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

 On 2017-03-06 14:03, Sean Dague  wrote:
>
> I'm trying to understand the implications of
> https://review.openstack.org/#/c/439500. And the comment in the linked
> email:
>
> ">> Yes, we decided some time ago to not translate the log files
> anymore and
>>>
>>> thus our tools do not handle them anymore - and in general, we remove
>>> these kind of files."
>
> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> fully removed? Nova currently enforces those things are there -
>
> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> and want to make sure our tools aren't making us do work that the i18n
> team is ignoring and throwing away.

 Sean, this was removed as followup to:


 http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

 Let me copy Ian as i18n PTL,

 Andreas
>>>
>>> That all seems reasonable, and I'm happy to follow the i18n team's lead
>>> here. It is however a significant reversal of policy, and there is
>>> substantial code infrastructure in projects (like Nova) to support the
>>> old policy.
>>>
>>> So if this is new policy, a much wider dissemination of it would be
>>> welcomed, as it means we can purge this infrastructure from projects
>>> like Nova.
>>>
>>>  -Sean
>>>
>> Yes, we went to a great deal of trouble to enable log translations,
>> so I'm surprised to see it being dropped to quickly.  I don't
>> necessarily disagree with the decision, because I know translator
>> time is limited. But it would be nice to have the discussion here,
>
>
> +1 and for such discussions including openstack-i...@lists.openstack.org
> mailing list would be also nice :)
>
> On Barcelona Design Summit, there were I18n contributor meetup and I18n team
> members discussed a lot.
> One of things was not to translate log-level strings for server projects.
>
> Note that such decision was made not because translator time is limited.
>
> Log messages are important to better identify which errors are being posed
> and most operators (+ developers)
> diagnose and start to solve error situations from the log messages.
> I18n team previously translated log messages a lot especially thanks to
> translation contribution from IBM. (AFAIK)
> However, after then, there have been some voices - why I18n team translated
> log messages?
> After listening to the voices in details, I18n team identified that the
> background of such voices was related with searching log messages on
> Internet.
> Searching English log messages on the Internet will retrieve more number of
> results than searching translated log messages on the Internet.
>
> Translating log messages now has two different point of views:
>  - Will be useful for OpenStack users to better understand log messages in
> details with translated log messages?
>  - Or will not be useful for OpenStack users because the original log
> messages will have better chance to find solutions who occurred the similar
> cases on the Internet?
>
> I18n team discussed with such point of views and on Barcelona Summit the
> latter point would be more important than the former point.
> Also, it would be just a point of view from PTL, but it is difficult for me
> to encourage to contribution translations which have such kind of
> controversy.
>
> Now I would like to listen again to not only developers, but also operators
> and translators - for log string translation.
> If someone thinks that the former point would be more important than the
> latter point, please share through this mailing list to reconsider the
> current decision.
>
>
> With many thanks,
>
> /Ian
>
>
>> instead of on a list most of the community isn't subscribed to, so
>> everyone involved can understand the reason for the change and so
>> the folks who asked for it originally can be included in the
>> conversation. As Sean points out, the policy change has a lot of
>> other implications about how logging is handled throughout the
>> applications.
>>
>> Doug
>>
>> 

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/7/2017 12:53 AM:

Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

Sean, this was removed as followup to:

http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

Let me copy Ian as i18n PTL,

Andreas

That all seems reasonable, and I'm happy to follow the i18n team's lead
here. It is however a significant reversal of policy, and there is
substantial code infrastructure in projects (like Nova) to support the
old policy.

So if this is new policy, a much wider dissemination of it would be
welcomed, as it means we can purge this infrastructure from projects
like Nova.

 -Sean


Yes, we went to a great deal of trouble to enable log translations,
so I'm surprised to see it being dropped to quickly.  I don't
necessarily disagree with the decision, because I know translator
time is limited. But it would be nice to have the discussion here,


+1 and for such discussions including openstack-i...@lists.openstack.org 
mailing list would be also nice :)


On Barcelona Design Summit, there were I18n contributor meetup and I18n 
team members discussed a lot.

One of things was not to translate log-level strings for server projects.

Note that such decision was made not because translator time is limited.

Log messages are important to better identify which errors are being 
posed and most operators (+ developers)

diagnose and start to solve error situations from the log messages.
I18n team previously translated log messages a lot especially thanks to 
translation contribution from IBM. (AFAIK)
However, after then, there have been some voices - why I18n team 
translated log messages?
After listening to the voices in details, I18n team identified that the 
background of such voices was related with searching log messages on 
Internet.
Searching English log messages on the Internet will retrieve more number 
of results than searching translated log messages on the Internet.


Translating log messages now has two different point of views:
 - Will be useful for OpenStack users to better understand log messages 
in details with translated log messages?
 - Or will not be useful for OpenStack users because the original log 
messages will have better chance to find solutions who occurred the 
similar cases on the Internet?


I18n team discussed with such point of views and on Barcelona Summit the 
latter point would be more important than the former point.
Also, it would be just a point of view from PTL, but it is difficult for 
me to encourage to contribution translations which have such kind of 
controversy.


Now I would like to listen again to not only developers, but also 
operators and translators - for log string translation.
If someone thinks that the former point would be more important than the 
latter point, please share through this mailing list to reconsider the 
current decision.



With many thanks,

/Ian


instead of on a list most of the community isn't subscribed to, so
everyone involved can understand the reason for the change and so
the folks who asked for it originally can be included in the
conversation. As Sean points out, the policy change has a lot of
other implications about how logging is handled throughout the
applications.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:
> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > On 2017-03-06 14:03, Sean Dague  wrote:
> >> I'm trying to understand the implications of
> >> https://review.openstack.org/#/c/439500. And the comment in the linked
> >> email:
> >>
> >> ">> Yes, we decided some time ago to not translate the log files anymore 
> >> and
>  thus our tools do not handle them anymore - and in general, we remove
>  these kind of files."
> >>
> >> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> >> fully removed? Nova currently enforces those things are there -
> >> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> >> and want to make sure our tools aren't making us do work that the i18n
> >> team is ignoring and throwing away.
> > 
> > Sean, this was removed as followup to:
> > 
> > http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html
> > 
> > Let me copy Ian as i18n PTL,
> > 
> > Andreas
> 
> That all seems reasonable, and I'm happy to follow the i18n team's lead
> here. It is however a significant reversal of policy, and there is
> substantial code infrastructure in projects (like Nova) to support the
> old policy.
> 
> So if this is new policy, a much wider dissemination of it would be
> welcomed, as it means we can purge this infrastructure from projects
> like Nova.
> 
> -Sean
> 

Yes, we went to a great deal of trouble to enable log translations,
so I'm surprised to see it being dropped to quickly.  I don't
necessarily disagree with the decision, because I know translator
time is limited. But it would be nice to have the discussion here,
instead of on a list most of the community isn't subscribed to, so
everyone involved can understand the reason for the change and so
the folks who asked for it originally can be included in the
conversation. As Sean points out, the policy change has a lot of
other implications about how logging is handled throughout the
applications.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> On 2017-03-06 14:03, Sean Dague  wrote:
>> I'm trying to understand the implications of
>> https://review.openstack.org/#/c/439500. And the comment in the linked
>> email:
>>
>> ">> Yes, we decided some time ago to not translate the log files anymore and
 thus our tools do not handle them anymore - and in general, we remove
 these kind of files."
>>
>> Does that mean that all the _LE, _LI, _LW stuff in projects should be
>> fully removed? Nova currently enforces those things are there -
>> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
>> and want to make sure our tools aren't making us do work that the i18n
>> team is ignoring and throwing away.
> 
> Sean, this was removed as followup to:
> 
> http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html
> 
> Let me copy Ian as i18n PTL,
> 
> Andreas

That all seems reasonable, and I'm happy to follow the i18n team's lead
here. It is however a significant reversal of policy, and there is
substantial code infrastructure in projects (like Nova) to support the
old policy.

So if this is new policy, a much wider dissemination of it would be
welcomed, as it means we can purge this infrastructure from projects
like Nova.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Andreas Jaeger]

On 2017-03-06 14:03, Sean Dague  wrote:
> I'm trying to understand the implications of
> https://review.openstack.org/#/c/439500. And the comment in the linked
> email:
> 
> ">> Yes, we decided some time ago to not translate the log files anymore and
>>> thus our tools do not handle them anymore - and in general, we remove
>>> these kind of files."
> 
> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> fully removed? Nova currently enforces those things are there -
> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> and want to make sure our tools aren't making us do work that the i18n
> team is ignoring and throwing away.

Sean, this was removed as followup to:

http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

Let me copy Ian as i18n PTL,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean Dague]

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and
>> thus our tools do not handle them anymore - and in general, we remove
>> these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev