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 <[email protected]>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
Date: Wednesday, March 22, 2017 at 7:54 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
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
<[email protected]<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
