Open Stack

On Thu, 21 Feb 2019, Doug Hellmann wrote:
> Matt Riedemann <mriedemos at gmail.com> writes:
>> As for the question at hand, I'm OK with *not* translating errors in
>> placement for both the admin-only aspect and the push to use standard
>> codes in error responses which can be googled.

[snip]

> I agree. If placement isn't meant for cloud end-users to interact with,
> I don't see a lot of benefit to translating the error messages coming
> through the API.

I started digging around in this again, and while I agree there's
little value in having the messages translated given the reasons
Matt states, the driving goal was to shrink the import weight (Babel
contributes ~25M (~15%)). However, we can't get that without also
removing oslo.i18n (and thus Babel) from:

     keystoneclient
     keystonemiddleware
     oslo.cache
     oslo.concurrency
     oslo.config
     oslo.db
     oslo.log
     oslo.middleware
     oslo.policy
     oslo.serialization
     oslo.upgradecheck
     oslo.utils

(Unless those happen to import it conditionally, I wouldn't except
them to.)

So this is a bit of a non-starter, at least for now and I don't see
a ton of point in removing the '_(..)' throughout placement. There
might be room for a discussion in the future about where in the
stack we encourage dependencies and translation, but how things are
now probably makes sense for the vast majority of cases.

For people who are trying to keep things small (in containers or
wherever) it's quite likely the Babel dat files can be deleted
during the container build without breaking things (since placement
has no po files). I'll look into that.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent