[PKG-Openstack-devel] "Recycle" debconf translations for murano/sahara?

[Thomas Goirand]

On 05/01/2015 08:16 AM, Christian PERRIER wrote:
> Hello fellow Openstack maintainers,
>
> I just noticed that two new packages of yours appeared in the archive,
> both of them with familiar debconf templates.
>
> I suspect that instead of having translators start over the
> localization work from scratch...or figure out which existing
> translation they could use as a basis, it could be good to "recycle"
> some existing translation files from another Openstack-related
> package.
>
> Still, not being widely familiar with your galaxy of packages, I have
> trouble figuring out which one would be good....that is, which one has
> templates that are identical to those in murano or sahara.
>
> If we can figure this out, then it would be nice to copy the PO files
> from that "template" package to the two new ones, then run
> "debconf-updatepo (which will "fuzzy" some strings) and then send a
> call for translation updates.
>
> Would you agree with that plan?

Hi,

I agree on the plan.

I would suggest that you have a look here:

http://docs.openstack.org/juno/install-guide/install/apt-debian/content/ch_debconf.html

A number of packages are re-using the same type of debconf screens for:
- dbconfig-common (basically, a yes/no switch)
- rabbitmq credentials (a login/password/host triplet)
- keystone_authtoken (tenant name, username, password, host)
- API endpoint (yes/no, host, region, admin_token)

The packages that are using this are:
- ceilometer
- cinder
- designate
- glance
- heat
- neutron
- nova
- murano
- openstack-trove
- sahara

Some are only using a subset of these.

I would very much love to have some kind of federation system so we 
don't get repetitive work going on at the translation level. We've 
already talked about it, but maybe we should find a better way.

There's already dbconfig-common for db. Maybe I should build something 
like it to avoid code duplication. What do you think? Any ideas? Any 
other example code which I should cheat on (the dbconfig-common code is 
kind of hard to follow...)?

Cheers,

Thomas Goirand (zigo)