On Thu, 21 Feb 2019, Doug Hellmann wrote:
Matt Riedemann mriedemos@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.