Open Stack

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 <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://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/f45950a1/attachment.html>