Open Stack

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 <pshchelokovskyy at mirantis.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Wednesday, March 22, 2017 at 7:54 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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 <lucasagomes at gmail.com<mailto:lucasagomes at gmail.com>> wrote:
Hi,

>> Possible options to handle that:
>>
>> 1)      Duplicate messages:
>>
>> LOG.error(“<error message>”, {<key>: <val>})
>>
>> raise Exception(_(“<error message>”) % {<key>: <val>})
>>
>> 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170322/9742e2b2/attachment.html>