Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500
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
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
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
> 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
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
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
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
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
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
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) 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 project worki
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/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
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
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
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
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
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
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
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
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
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 >> >> __ >> Ope
Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500
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
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
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
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