On 12/30/2015 07:22 PM, Akihiro Motoki wrote:
Thanks for initiating this effort.
2015-12-29 6:28 GMT+09:00 Andreas Jaeger <a...@suse.com>:
Reading some IRC backlog and an incoming review with a new suggestion on how
to do translations in the project, I decided to write some problems our
current scripts have, together with questions and proposals. With the
growing big tent and the automatic way to setup translations, we get more
repos requesting translations - and more support requests.
Please read the description below and tell me what's wrong,what's missing,
where you disagree - and how to move forward.
thanks,
Andreas
Setting up translations for new projects currently has the following
challenges:
a) For "python" repositories, we expect that the locale file is
located at $repo/locale/$repo.pot - without any change possible.
This leads to python-novaclient/locale/python-novaclient.pot and
oslo.log/locale/oslo.log.i18n - in both cases the python module has
a different name, novaclient and oslo_log.
Currently everybody makes it wrong and we have to help them using
the proper file names.
Proposal:
* Simplify location to use $modulename/locale/$modulename
Can we determine modulename easily from the name in setup.cfg like
in jenkins/scripts/pypi-extract-name.py?
IMO it is better to keep a domain name. The domain name means a filename.
The domain name is specified in oslo.i18n wrapper and setup.cfg.
Changing the directory name helps a lot, but changing the basename helps little.
My proposal is $modulename/locale/$reponame, but either of them is okay to me.
Isn't the domainname the same as modulename? I just checked
python-novaclient and it uses as domainname novaclient.
b) For dashboard repos, there's no common entry point yet and some are
even setup like "python" repositories (designate-dashboard).
It is a good idea to add some common entry point (tox target).
There's also no naming pattern on how to name files and everybody
does it differently.
Currently the django component is called djangjo.pot, the
javascript one djangojs.pot.
Question: Do we really need to do it this way or can we change it?
We should have a single entrypoint for projects and a standard way
to call them.
Proposal: Define standard tox environement "extractmessages", it
places translation files in (if django/djangojs are really the best
names, I prefer to change them):
* $modulename/locale/django.pot
* $modulename/locale/djangojs.pot
Can we determine modulename easily from the name in setup.cfg like
in jenkins/scripts/pypi-extract-name.py? At least
django_openstack_auth is setup differently..
As far as I know it is not easy to change.
Looking at
https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#specialties-of-django-translation,
The django framework expects django and djangojs as a domain name.
Message catalogs should be placed in 'locale' directory under each
django application path,
i.e. $modulename/locale/. It works most dashboard repository, but
'horizon' repo is special.
Horizon repo uses two django applications, openstack_dashboard and
horizon and this means
we need horizon/locale and openstack_dashboard/locale.
If we forces $modulename/locale/, it breaks Horizon implementation.
Ok, we need to make an exception here. Let me update my draft spec for this.
# Horizon team explored to split openstack_dashboard and horizon, but
there seems no much value
# at the moment and the effort is now stopped (or abandoned).
c) Projects currently need to add the pot file initially, our scripts
fail if the directory does not exist.
Proposal: Make scripts robust so that they work even without
initial pot file.
It sounds a good idea.
If 'translate' tag is specified in project-config/gerrit/projects.yaml,
it would be nice that POT file is generated automatically.
Exactly.
thanks for your comments,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
