Horizon git repo shouldn't include the .mo files

[Thomas Goirand]

There is no reason why Horizon should include the .mo files. They are binary files, which makes them very good candidate for merge failures. Also, they are supposed to be generated out of the .po files, and to enforce that .mo are generated from source, a good way is to simply remove them from the Git repository.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/35330

[Julie Pichon (jpichon)]

Adding a task on django_openstack_auth, which should follow the same policy.

IIRC the problem with the initial patch was that we wanted to regenerate the mo files automatically later. I'm not sure how the other OpenStack projects handle this?

[Akihiro Motoki (amotoki)]

There is no OpenStack project which compiles message catalogs automatically.
Unless distribution packaging does not deal with it, users do not have any compiled messaged catalog.
This does not matter at the moment because most projects have no translations.

IMO the right way is to add a hook mechanism to pbr as Monty suggested in the above review.
I am not sure we need to support two mechanism (babel and dajngo) or we can do it in a single way.
Anyway I18N team need to initiate and work on it.
Until then it sounds reasonable Horizon and django_openstack_auth have MO files in their repos and distributions.

[Thomas Goirand (thomas-goirand)]

Hi Akihiro,

It's IMO not reasonable, because it constantly creates merge conflicts, and adds nothing. I don't see why generating the .mo files in the setup.py install process is wrong. That PBR should do it, probably, but I don't think it is a reason good enough for refusing to do something about it now, before PBR has the feature.

[Akihiro Motoki (amotoki)]

Hi Thomas,

I don't think it is not reasonable that generating .mo file in the setup.py.
OpenStack has many projects so ideally it is good to do a thing like this in pbr (or common module).

What plan is good?

(1) First remove .mo files in Horizon repository and setup.py does nothing. And prepare setup.py later. (In this case deployer or distributer takes care of generating .mo files)
(2) Remove .mo files in Horizon repository and prepare a hook in setup.py in Horizon at the same time. The hook is Horizon specific.
(3) Remove .mo files in Horizon repository and use new pbr with a support to generate .mo files.

Plan #2 was proposed but there is an objection on the approach. I have no better idea on plan #2 now.

[Thomas Goirand (thomas-goirand)]

Hi,

I agree it would be nice to have the .mo generated by a common script in OpenStack. PBR comes to mind, though I think it may be best to first do it in oslo-incubator, then only when it's proven to work, move it somewhere else.

I don't think it's reasonable to off-load the .mo generation to the distributions. Such a script isn't hard to write, though it would be redundant work (it would have to be done separately in RedHat, Debian, Ubuntu, Arch, Gentoo... you name it). Also, we need to have the .mo generated for devstack and all.

I agree that plan #2 is the most reasonable *for now*. It can be improved later on. I don't think it has been rejected because it's in setup.py, I think it has been rejected because of my poor implementation using gettext shell tools directly. If we come with a solution directly in PBR, using python only, then I think it's going to be approved. Unfortunately, I have no time to work on that right now, especially if I risk to have many patch rejections again (I do too much already and I got a huge backlog of stuff to work on for packaging OpenStack Juno in Debian...).

[Akihiro Motoki (amotoki)]

We discussed and agree the following in the dev list [1]:
This policy is applied from Juno release.

* Remove MO files.
* Compiling message catalogs is up to deployers/distributors
* Add the instruction on how to compile message catalogs

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/thread.html#47568

The action items are:
* (a) Remove MO files from the git repo
* (b) Add the instruction on how to compile message catalogs

[Juno]
* Action Item (a): Covered as a part of bug 1376542
* Action Item (b): Can be covered by backporting https://review.openstack.org/#/c/126169/

[Kilo release]
* Action Item (a): Proposed a change to remove MO files
* Action Item (b): https://review.openstack.org/#/c/126169/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/127338

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/127338
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=06657c650249546b8add6cb03911870f693e05b9
Submitter: Jenkins
Branch: master

commit 06657c650249546b8add6cb03911870f693e05b9
Author: Akihiro Motoki <email address hidden>
Date: Fri Oct 10 05:29:01 2014 +0900

    Remove compiled message catalogs

    A kind of binary files are useless to be maintained in git repo.
    I18N team and package distributors have agreed to remove compiled
    message catalogs from Horizon git repository.

    The instruction on how to compile message catalogs will be
    covered by https://review.openstack.org/#/c/126169/
    or the installation guide.

    DocImpact

    Change-Id: I81b05cf79c21d85bed8a6da6df659955e7ac58c5
    Closes-Bug: #1196982

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/127706

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/127706
Committed: https://git.openstack.org/cgit/openstack/django_openstack_auth/commit/?id=dd08c15086a4aa4966b2190a19b02b2605649ce7
Submitter: Jenkins
Branch: master

commit dd08c15086a4aa4966b2190a19b02b2605649ce7
Author: Akihiro Motoki <email address hidden>
Date: Sat Oct 11 11:18:52 2014 +0900

    Remove compiled message catalogs

    A kind of binary files are useless to be maintained in git repo.
    I18N team and package distributors have agreed to remove compiled
    message catalogs from openstack-auth git repository.

    To compile message catalogs, run the following command before
    the installation:

      python setup.py compile_catalog

    Make sure to install Babel>=1.3 before running the above command.

    DocImpact
    Closes-Bug: #1196982

    Change-Id: Iab2398e942e142f9ab370d8a8f9d539b257e1620