Re: [openstack-dev] [ironic] Translations removal

[Dmitry Tantsur]

On 03/30/2017 08:36 PM, Doug Hellmann wrote:

Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:

On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:

On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:

However, pep8 does not accept passing variable to translation
functions,  so this results in ‘H701 Empty localization string’ error.

Possible options to handle that:

1)  Duplicate messages:

LOG.error(“”, {: })

raise Exception(_(“”) % {: })

2)  Ignore this error

3)  Talk to hacking people about possible upgrade of this check

4)  Pass translated text to LOG in such cases



I’d personally vote for 2. What are your thoughts?


When the translators go to translate, they generally only get to see
what's inside _(), so #2 is a no-go for translations, and #3 also is a
no-go.
--


I think the appropriate thing here is to do something like:

msg = _('') % {: }
LOG.error(msg)
raise Exception(msg)

This results in a translated string going to the log, but I think that's
OK.



Why is the error being logged and then thrown? If it's a true exception,
won't the outer-most part of the application loop log the error? And if
it's something that the application is catching and handling, that makes
it seem like it's not an operator-facing error.


This sounds nice, and we did it for some time. But it ends up being a 
debugability nightmare, so now I usually -1 people for not having this 
LOG.error. This is because every re-raise loses some valuable information; 
crossing the RPC border probably loses even more. It is particularly bad, when 
the error messages from innermost exceptions are not helpful (hello, KeyError).


My personal favorite case was something like:

 "Failed to power off the node . Unable to parse XML."

Getting something like that in ironic-api logs would probably not be too 
helpful.



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] [ironic] Translations removal

[Jim Rollenhagen]

On Thu, Mar 30, 2017 at 3:24 PM, Doug Hellmann 
wrote:

> Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:
> > On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann 
> > wrote:
> >
> > > Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > > > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > > > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > > > > However, pep8 does not accept passing variable to translation
> > > > > > functions,  so this results in ‘H701 Empty localization string’
> > > error.
> > > > > >
> > > > > > Possible options to handle that:
> > > > > >
> > > > > > 1)  Duplicate messages:
> > > > > >
> > > > > > LOG.error(“”, {: })
> > > > > >
> > > > > > raise Exception(_(“”) % {: })
> > > > > >
> > > > > > 2)  Ignore this error
> > > > > >
> > > > > > 3)  Talk to hacking people about possible upgrade of this
> check
> > > > > >
> > > > > > 4)  Pass translated text to LOG in such cases
> > > > > >
> > > > > >
> > > > > >
> > > > > > I’d personally vote for 2. What are your thoughts?
> > > > >
> > > > > When the translators go to translate, they generally only get to
> see
> > > > > what's inside _(), so #2 is a no-go for translations, and #3 also
> is a
> > > > > no-go.
> > > > > --
> > > >
> > > > I think the appropriate thing here is to do something like:
> > > >
> > > > msg = _('') % {: }
> > > > LOG.error(msg)
> > > > raise Exception(msg)
> > > >
> > > > This results in a translated string going to the log, but I think
> that's
> > > > OK.
> > > >
> > >
> > > Why is the error being logged and then thrown? If it's a true
> exception,
> > > won't the outer-most part of the application loop log the error? And if
> > > it's something that the application is catching and handling, that
> makes
> > > it seem like it's not an operator-facing error.
> > >
> >
> > That's a good point. Without looking for examples, I suspect there's a
> few
> > reasons here:
> >
> > 1) in ironic, the operator and API user are often the same person
> > 2) ironic deals with hardware. Often, errors that are returned to the
> user
> > are
> >something only the operator can fix.
> > 3) Nova is a heavy user of the ironic API - errors returned to nova may
> not
> > be
> >seen by the user, but the operator needs to see it somewhere (though
> it
> >is easy to argue those shouldn't be translated).
> >
> > // jim
>
> I guess my point was that unhandled exceptions should all be handled
> by the Ironic API service code before the response is delivered,
> rather than having them handled in the code that is throwing the
> exception. If the exception is handled, that makes the message a warning
> or info log message, not an error, under our guidelines [1].
>
> [1] http://specs.openstack.org/openstack/openstack-specs/
> specs/log-guidelines.html


Fair enough. Maybe the folks removing translations can work on this while
they are in the code already. :)

// jim
__
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] [ironic] Translations removal

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:
> On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > > > However, pep8 does not accept passing variable to translation
> > > > > functions,  so this results in ‘H701 Empty localization string’
> > error.
> > > > >
> > > > > Possible options to handle that:
> > > > >
> > > > > 1)  Duplicate messages:
> > > > >
> > > > > LOG.error(“”, {: })
> > > > >
> > > > > raise Exception(_(“”) % {: })
> > > > >
> > > > > 2)  Ignore this error
> > > > >
> > > > > 3)  Talk to hacking people about possible upgrade of this check
> > > > >
> > > > > 4)  Pass translated text to LOG in such cases
> > > > >
> > > > >
> > > > >
> > > > > I’d personally vote for 2. What are your thoughts?
> > > >
> > > > When the translators go to translate, they generally only get to see
> > > > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > > > no-go.
> > > > --
> > >
> > > I think the appropriate thing here is to do something like:
> > >
> > > msg = _('') % {: }
> > > LOG.error(msg)
> > > raise Exception(msg)
> > >
> > > This results in a translated string going to the log, but I think that's
> > > OK.
> > >
> >
> > Why is the error being logged and then thrown? If it's a true exception,
> > won't the outer-most part of the application loop log the error? And if
> > it's something that the application is catching and handling, that makes
> > it seem like it's not an operator-facing error.
> >
> 
> That's a good point. Without looking for examples, I suspect there's a few
> reasons here:
> 
> 1) in ironic, the operator and API user are often the same person
> 2) ironic deals with hardware. Often, errors that are returned to the user
> are
>something only the operator can fix.
> 3) Nova is a heavy user of the ironic API - errors returned to nova may not
> be
>seen by the user, but the operator needs to see it somewhere (though it
>is easy to argue those shouldn't be translated).
> 
> // jim

I guess my point was that unhandled exceptions should all be handled
by the Ironic API service code before the response is delivered,
rather than having them handled in the code that is throwing the
exception. If the exception is handled, that makes the message a warning
or info log message, not an error, under our guidelines [1].

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.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] [ironic] Translations removal

[Jim Rollenhagen]

On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann 
wrote:

> Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > > However, pep8 does not accept passing variable to translation
> > > > functions,  so this results in ‘H701 Empty localization string’
> error.
> > > >
> > > > Possible options to handle that:
> > > >
> > > > 1)  Duplicate messages:
> > > >
> > > > LOG.error(“”, {: })
> > > >
> > > > raise Exception(_(“”) % {: })
> > > >
> > > > 2)  Ignore this error
> > > >
> > > > 3)  Talk to hacking people about possible upgrade of this check
> > > >
> > > > 4)  Pass translated text to LOG in such cases
> > > >
> > > >
> > > >
> > > > I’d personally vote for 2. What are your thoughts?
> > >
> > > When the translators go to translate, they generally only get to see
> > > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > > no-go.
> > > --
> >
> > I think the appropriate thing here is to do something like:
> >
> > msg = _('') % {: }
> > LOG.error(msg)
> > raise Exception(msg)
> >
> > This results in a translated string going to the log, but I think that's
> > OK.
> >
>
> Why is the error being logged and then thrown? If it's a true exception,
> won't the outer-most part of the application loop log the error? And if
> it's something that the application is catching and handling, that makes
> it seem like it's not an operator-facing error.
>

That's a good point. Without looking for examples, I suspect there's a few
reasons here:

1) in ironic, the operator and API user are often the same person
2) ironic deals with hardware. Often, errors that are returned to the user
are
   something only the operator can fix.
3) Nova is a heavy user of the ironic API - errors returned to nova may not
be
   seen by the user, but the operator needs to see it somewhere (though it
   is easy to argue those shouldn't be translated).

// jim
__
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] [ironic] Translations removal

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > However, pep8 does not accept passing variable to translation
> > > functions,  so this results in ‘H701 Empty localization string’ error.
> > > 
> > > Possible options to handle that:
> > > 
> > > 1)  Duplicate messages:
> > > 
> > > LOG.error(“”, {: })
> > > 
> > > raise Exception(_(“”) % {: })
> > > 
> > > 2)  Ignore this error
> > > 
> > > 3)  Talk to hacking people about possible upgrade of this check
> > > 
> > > 4)  Pass translated text to LOG in such cases
> > > 
> > >  
> > > 
> > > I’d personally vote for 2. What are your thoughts?
> > 
> > When the translators go to translate, they generally only get to see
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > no-go.
> > -- 
> 
> I think the appropriate thing here is to do something like:
> 
> msg = _('') % {: }
> LOG.error(msg)
> raise Exception(msg)
> 
> This results in a translated string going to the log, but I think that's
> OK.
> 

Why is the error being logged and then thrown? If it's a true exception,
won't the outer-most part of the application loop log the error? And if
it's something that the application is catching and handling, that makes
it seem like it's not an operator-facing error.

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] [ironic] Translations removal

[Jim Rollenhagen]

On Wed, Mar 22, 2017 at 11:44 AM, Sean McGinnis 
wrote:

> On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > However, pep8 does not accept passing variable to translation
> > > functions,  so this results in ‘H701 Empty localization string’ error.
> > >
> > > Possible options to handle that:
> > >
> > > 1)  Duplicate messages:
> > >
> > > LOG.error(“”, {: })
> > >
> > > raise Exception(_(“”) % {: })
> > >
> > > 2)  Ignore this error
> > >
> > > 3)  Talk to hacking people about possible upgrade of this check
> > >
> > > 4)  Pass translated text to LOG in such cases
> > >
> > >
> > >
> > > I’d personally vote for 2. What are your thoughts?
> >
> > When the translators go to translate, they generally only get to see
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > no-go.
> > --
>
> I think the appropriate thing here is to do something like:
>
> msg = _('') % {: }
> LOG.error(msg)
> raise Exception(msg)
>
> This results in a translated string going to the log, but I think that's
> OK.
>

+1, let's not overcomplicate this. If folks report it as a problem, we
can always go back to option 1 later.

// jim
__
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] [ironic] Translations removal

[Kevin L. Mitchell]

On Wed, 2017-03-22 at 18:44 +, Taryma, Joanna wrote:
> Thanks for pointing out that 2 and 3 won’t actually work, I apologize
> for the confusion it could’ve created.
> 
>  
> 
> I don’t like the option 6, because making user-messages friendlier was
> the whole purpose of translation. Mixing languages in exception would
> be even worse than doing it in logs, IMHO. What is more – if there’s a
> custom message passed to exception (e.g. MyException(“My message” %
> {k: v}), it overwrites the default one, so it would end up with
> English-only message.
> 
>  
> 
> Option 5 looks nice (and easy), but I don’t think that it will be very
> good if all other components will allow showing translated messages
> and Ironic won’t.
> 
> Seems like *if* we want to translate entire exception messages, we’re
> left with option 1 only, right?

It occurred to me that i18n may provide a means of handling this
directly; I don't know for sure, but one of the library developers could
probably comment.  IIRC, i18n uses (or can use) "lazy translation",
where it keeps around the original message but only translates it on
output.  If that's the case, that may help provide a solution to
translate user-visible messages while leaving logs untranslated.
-- 
Kevin L. Mitchell 


signature.asc
Description: This is a digitally signed message part
__
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] [ironic] Translations removal

[Taryma, Joanna]

Hi,

Thanks for pointing out that 2 and 3 won’t actually work, I apologize for the 
confusion it could’ve created.

I don’t like the option 6, because making user-messages friendlier was the 
whole purpose of translation. Mixing languages in exception would be even worse 
than doing it in logs, IMHO. What is more – if there’s a custom message passed 
to exception (e.g. MyException(“My message” % {k: v}), it overwrites the 
default one, so it would end up with English-only message.

Option 5 looks nice (and easy), but I don’t think that it will be very good if 
all other components will allow showing translated messages and Ironic won’t.
Seems like *if* we want to translate entire exception messages, we’re left with 
option 1 only, right?

Regards,
Joanna

From: Pavlo Shchelokovskyy <pshchelokovs...@mirantis.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, March 22, 2017 at 7:54 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] Translations removal

HI all,

my 5 cents:

- option 1) is ugly due to code/string duplication;
- options 2) and 3) are not going to work for translators as others already 
pointed;
- option 4) has a caveat that we should do it consistently - either translate 
all or translate none, so there won't be a mess of log messages written in 
different languages at seemingly random;
- option 5) from Lucas looks nice and easy, but I'm afraid we still have to 
i18n the errors returned to end user in API responses.

So how about half-solution 6) - reorg our exception messages (at least those 
returned from API) to always include some string that is i18n'ed in the 
exception class declaration itself, but may have part of strings passed in at 
instantiation, so nowhere the whole exception message is completely passed in 
when instantiating the exception. Downside is that final exception message may 
be returned in two languages (half i18n'ed, half English).

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com<http://www.mirantis.com>

On Wed, Mar 22, 2017 at 4:13 PM, Lucas Alvares Gomes 
<lucasago...@gmail.com<mailto:lucasago...@gmail.com>> wrote:
Hi,

>> Possible options to handle that:
>>
>> 1)  Duplicate messages:
>>
>> LOG.error(“”, {: })
>>
>> raise Exception(_(“”) % {: })
>>
>> 2)  Ignore this error
>>
>> 3)  Talk to hacking people about possible upgrade of this check
>>
>> 4)  Pass translated text to LOG in such cases
>>
>>
>>
>> I’d personally vote for 2. What are your thoughts?
>
> When the translators go to translate, they generally only get to see
> what's inside _(), so #2 is a no-go for translations, and #3 also is a
> no-go.

+1

Just throwing and idea here: Is not translating anything an option ?

Personally I don't see much benefits in translating a software like
Ironic, there are many "user facing" parts that will remain in
english, e.g: The resource attributes name, node's states (powered
off, powered on, deploying, deploy wait...), etc... So why bother ? I
think it's fair to assume that people using Ironic directly (not via
horizon for example) understands english. It's a lot of overhead to
get it translated and there are very few people working on it for
Ironic (right now, Ironic is 2.74% translated [0]). IMHO just the
costs of having duplicated strings all over in the code overweight the
benefits.

I did some translation of Ironic to Brazilian Portuguese in the past
myself and it's really tough to keep up the pace, strings are added or
changed very rapidly.

So again, is:  "5) Not translate anything" an option here ?

[0] https://translate.openstack.org/iteration/view/ironic/master?dswid=9016

Cheers,
Lucas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [ironic] Translations removal

[Tom Barron]

On 03/22/2017 11:44 AM, Sean McGinnis wrote:
> On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
>> On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
>>> However, pep8 does not accept passing variable to translation
>>> functions,  so this results in ‘H701 Empty localization string’ error.
>>>
>>> Possible options to handle that:
>>>
>>> 1)  Duplicate messages:
>>>
>>> LOG.error(“”, {: })
>>>
>>> raise Exception(_(“”) % {: })
>>>
>>> 2)  Ignore this error
>>>
>>> 3)  Talk to hacking people about possible upgrade of this check
>>>
>>> 4)  Pass translated text to LOG in such cases
>>>
>>>  
>>>
>>> I’d personally vote for 2. What are your thoughts?
>>
>> When the translators go to translate, they generally only get to see
>> what's inside _(), so #2 is a no-go for translations, and #3 also is a
>> no-go.
>> -- 
> 
> I think the appropriate thing here is to do something like:
> 
> msg = _('') % {: }
> LOG.error(msg)
> raise Exception(msg)
> 
> This results in a translated string going to the log, but I think that's
> OK.
>

Yeah, that is what we are starting to do going forwards unless
instructed otherwise.


> 
> __
> 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] [ironic] Translations removal

[Sean McGinnis]

On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > However, pep8 does not accept passing variable to translation
> > functions,  so this results in ‘H701 Empty localization string’ error.
> > 
> > Possible options to handle that:
> > 
> > 1)  Duplicate messages:
> > 
> > LOG.error(“”, {: })
> > 
> > raise Exception(_(“”) % {: })
> > 
> > 2)  Ignore this error
> > 
> > 3)  Talk to hacking people about possible upgrade of this check
> > 
> > 4)  Pass translated text to LOG in such cases
> > 
> >  
> > 
> > I’d personally vote for 2. What are your thoughts?
> 
> When the translators go to translate, they generally only get to see
> what's inside _(), so #2 is a no-go for translations, and #3 also is a
> no-go.
> -- 

I think the appropriate thing here is to do something like:

msg = _('') % {: }
LOG.error(msg)
raise Exception(msg)

This results in a translated string going to the log, but I think that's
OK.


__
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] [ironic] Translations removal

[Pavlo Shchelokovskyy]

HI all,

my 5 cents:

- option 1) is ugly due to code/string duplication;
- options 2) and 3) are not going to work for translators as others already
pointed;
- option 4) has a caveat that we should do it consistently - either
translate all or translate none, so there won't be a mess of log messages
written in different languages at seemingly random;
- option 5) from Lucas looks nice and easy, but I'm afraid we still have to
i18n the errors returned to end user in API responses.

So how about half-solution 6) - reorg our exception messages (at least
those returned from API) to always include some string that is i18n'ed in
the exception class declaration itself, but may have part of strings passed
in at instantiation, so nowhere the whole exception message is completely
passed in when instantiating the exception. Downside is that final
exception message may be returned in two languages (half i18n'ed, half
English).

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Mar 22, 2017 at 4:13 PM, Lucas Alvares Gomes 
wrote:

> Hi,
>
> >> Possible options to handle that:
> >>
> >> 1)  Duplicate messages:
> >>
> >> LOG.error(“”, {: })
> >>
> >> raise Exception(_(“”) % {: })
> >>
> >> 2)  Ignore this error
> >>
> >> 3)  Talk to hacking people about possible upgrade of this check
> >>
> >> 4)  Pass translated text to LOG in such cases
> >>
> >>
> >>
> >> I’d personally vote for 2. What are your thoughts?
> >
> > When the translators go to translate, they generally only get to see
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > no-go.
>
> +1
>
> Just throwing and idea here: Is not translating anything an option ?
>
> Personally I don't see much benefits in translating a software like
> Ironic, there are many "user facing" parts that will remain in
> english, e.g: The resource attributes name, node's states (powered
> off, powered on, deploying, deploy wait...), etc... So why bother ? I
> think it's fair to assume that people using Ironic directly (not via
> horizon for example) understands english. It's a lot of overhead to
> get it translated and there are very few people working on it for
> Ironic (right now, Ironic is 2.74% translated [0]). IMHO just the
> costs of having duplicated strings all over in the code overweight the
> benefits.
>
> I did some translation of Ironic to Brazilian Portuguese in the past
> myself and it's really tough to keep up the pace, strings are added or
> changed very rapidly.
>
> So again, is:  "5) Not translate anything" an option here ?
>
> [0] https://translate.openstack.org/iteration/view/ironic/
> master?dswid=9016
>
> Cheers,
> Lucas
>
> __
> 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] [ironic] Translations removal

[Lucas Alvares Gomes]

Hi,

>> Possible options to handle that:
>>
>> 1)  Duplicate messages:
>>
>> LOG.error(“”, {: })
>>
>> raise Exception(_(“”) % {: })
>>
>> 2)  Ignore this error
>>
>> 3)  Talk to hacking people about possible upgrade of this check
>>
>> 4)  Pass translated text to LOG in such cases
>>
>>
>>
>> I’d personally vote for 2. What are your thoughts?
>
> When the translators go to translate, they generally only get to see
> what's inside _(), so #2 is a no-go for translations, and #3 also is a
> no-go.

+1

Just throwing and idea here: Is not translating anything an option ?

Personally I don't see much benefits in translating a software like
Ironic, there are many "user facing" parts that will remain in
english, e.g: The resource attributes name, node's states (powered
off, powered on, deploying, deploy wait...), etc... So why bother ? I
think it's fair to assume that people using Ironic directly (not via
horizon for example) understands english. It's a lot of overhead to
get it translated and there are very few people working on it for
Ironic (right now, Ironic is 2.74% translated [0]). IMHO just the
costs of having duplicated strings all over in the code overweight the
benefits.

I did some translation of Ironic to Brazilian Portuguese in the past
myself and it's really tough to keep up the pace, strings are added or
changed very rapidly.

So again, is:  "5) Not translate anything" an option here ?

[0] https://translate.openstack.org/iteration/view/ironic/master?dswid=9016

Cheers,
Lucas

__
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] [ironic] Translations removal

[Kevin L. Mitchell]

On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> However, pep8 does not accept passing variable to translation
> functions,  so this results in ‘H701 Empty localization string’ error.
> 
> Possible options to handle that:
> 
> 1)  Duplicate messages:
> 
> LOG.error(“”, {: })
> 
> raise Exception(_(“”) % {: })
> 
> 2)  Ignore this error
> 
> 3)  Talk to hacking people about possible upgrade of this check
> 
> 4)  Pass translated text to LOG in such cases
> 
>  
> 
> I’d personally vote for 2. What are your thoughts?

When the translators go to translate, they generally only get to see
what's inside _(), so #2 is a no-go for translations, and #3 also is a
no-go.
-- 
Kevin L. Mitchell 


signature.asc
Description: This is a digitally signed message part
__
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] [ironic] Translations removal

[Vladyslav Drok]

On Wed, Mar 22, 2017 at 12:10 AM, Taryma, Joanna 
wrote:

> Hi team,
>
>
>
> As discussed on Monday, logged messages shouldn’t be translated anymore.
> Exception messages still should be still translated.
>
> While removing usages of _LE, _LW, _LI should be fairly easy, some usages
> of _ may cause issues.
>
>
>
> Some messages in the code are declared with ‘_’ method and used both for
> logger and exception. This has to be changed, so we don’t have some log
> entries translated because of that.
>
> The best option in terms of code redundancy would be something like:
>
> msg = “”
>
> LOG.error(msg, {: })
>
> raise Exception(_(msg) % {: })
>
>
>
> However, pep8 does not accept passing variable to translation functions,
> so this results in ‘H701 Empty localization string’ error.
>
> Possible options to handle that:
>
> 1)   Duplicate messages:
>
> LOG.error(“”, {: })
>
> raise Exception(_(“”) % {: })
>
> 2)   Ignore this error
>
> 3)   Talk to hacking people about possible upgrade of this check
>
> 4)   Pass translated text to LOG in such cases
>
>
>
> I’d personally vote for 2. What are your thoughts?
>

I don't think we can simply ignore it --
https://docs.openstack.org/developer/oslo.i18n/guidelines.html#using-a-marker-function,
it is just a marker for i18n IIUC, and if we'll change to just doing
_(var), it will not be translated.

-Vlad


>
>
> Kind regards,
>
> Joanna
>
>
>
> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-
> ironic/%23openstack-ironic.2017-03-21.log.html#t2017-03-21T14:00:49
>
> __
> 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