<div dir="ltr">HI all,<div><br></div><div>my 5 cents:</div><div><br></div><div>- option 1) is ugly due to code/string duplication;</div><div>- options 2) and 3) are not going to work for translators as others already pointed;</div><div>- 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;</div><div>- 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.</div><div><br></div><div>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).</div><div><br></div><div>Cheers,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 22, 2017 at 4:13 PM, Lucas Alvares Gomes <span dir="ltr"><<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
>> Possible options to handle that:<br>
>><br>
>> 1)      Duplicate messages:<br>
>><br>
>> LOG.error(“<error message>”, {<key>: <val>})<br>
>><br>
>> raise Exception(_(“<error message>”) % {<key>: <val>})<br>
>><br>
>> 2)      Ignore this error<br>
>><br>
>> 3)      Talk to hacking people about possible upgrade of this check<br>
>><br>
>> 4)      Pass translated text to LOG in such cases<br>
>><br>
>><br>
>><br>
>> I’d personally vote for 2. What are your thoughts?<br>
><br>
> When the translators go to translate, they generally only get to see<br>
> what's inside _(), so #2 is a no-go for translations, and #3 also is a<br>
> no-go.<br>
<br>
</span>+1<br>
<br>
Just throwing and idea here: Is not translating anything an option ?<br>
<br>
Personally I don't see much benefits in translating a software like<br>
Ironic, there are many "user facing" parts that will remain in<br>
english, e.g: The resource attributes name, node's states (powered<br>
off, powered on, deploying, deploy wait...), etc... So why bother ? I<br>
think it's fair to assume that people using Ironic directly (not via<br>
horizon for example) understands english. It's a lot of overhead to<br>
get it translated and there are very few people working on it for<br>
Ironic (right now, Ironic is 2.74% translated [0]). IMHO just the<br>
costs of having duplicated strings all over in the code overweight the<br>
benefits.<br>
<br>
I did some translation of Ironic to Brazilian Portuguese in the past<br>
myself and it's really tough to keep up the pace, strings are added or<br>
changed very rapidly.<br>
<br>
So again, is:  "5) Not translate anything" an option here ?<br>
<br>
[0] <a href="https://translate.openstack.org/iteration/view/ironic/master?dswid=9016" rel="noreferrer" target="_blank">https://translate.openstack.<wbr>org/iteration/view/ironic/<wbr>master?dswid=9016</a><br>
<br>
Cheers,<br>
Lucas<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>