babel extractors are now registered via python entry points,
so there is no need to declare babel extractors in babel configs.
This change is important to make translation work in Django 2.2.
django-babel does not work with Django 2.2 and looks unmaintained
for over two years. The horizon team is thinking to switch the extractor
to enmerkar (a fork of django-babel) to make extraction of translation
string work again near future. It is important to drop the extractor
definition to make the transition smooth.
Change-Id: Ideff438f8100a330c49c6ae087d9bf7d4f540d29
In Liberty, sahara-dashboard supports translations, but does not now.
Once this patch is merged, we can enable the infra tranlation jobs.
* Prepare babel-{django|djangojs}.cfg so that the infra script
extracts message catalogs [1]
* Update devstack plugin to compile message catalogs
* Remove babel related entries in setup.cfg because it does not
work for horizon plugins. Babel does not support message extraction
for multiple domains.
* Create symlink sahara_dashboard/content/data_processing/locale
(which points to sahara_dashboard/locale)
The infra translation script assumes <modulename>/locale as
locale dir. On the other hand, sahara dashboard registers
"sahara_dashboard.content.data_processing" in INSTALLED_APPS.
Django search locale data from <apps>/locale for each INSTALLED_APPS.
Thus this symlink is required to make translation work.
Note that I am not sure why sahara dashboard uses
"sahara_dashboard.content.data_processing" as INSTALLED_APPS unlike
other horizon related projects, but it needs more investigation
and this patch does not touch it at the moment.
[1] http://docs.openstack.org/infra/manual/creators.html#enabling-translation-infrastructure
Change-Id: I93609a1af08b5a6f64fc43c16722f4c759f68302