Open Stack

Thanks for initiating this effort.

2015-12-29 6:28 GMT+09:00 Andreas Jaeger <aj at 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.

> 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.

# 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.

Akihiro

>
> --
>  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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra