LOCALE_PATH causes message mo files not found

[Gloria Gu]

Current default LOCALE_PATH is defined in openstack_dashboard/settings.py, like
LOCALE_PATHS = [
    'horizon/locale',
    'openstack_dashboard/locale'
]

They work fine in the development environment. However if Horizon path installed in production is like

/opt/stack/venv/horizon-20180814T161452Z/srv/www/openstack-dashboard/openstack_dashboard
/opt/stack/venv/horizon-20180814T161452Z/lib/python2.7/site-packages/horizon/

when reset locale in the settings, the selected settings won't get saved and the translation won't happen.

because of the relative locale path in settings.py, without overwriting the path in local_settings.py.

/openstack_dashboard/dashboards/settings/user/forms.py
check_for_language returns false

  if lang_code and translation.check_for_language(lang_code):
            response = functions.save_config_value(
                request, response, settings.LANGUAGE_COOKIE_NAME, lang_code)

updated settings.py seem to fix the problem, however, still not clear what to do with horizon/locale
Change LOCALE_PATHS = [
    'horizon/locale',
    # 'openstack_dashboard/locale',
    os.path.join(ROOT_PATH, "locale")
]

[Akihiro Motoki (amotoki)]

As described in the django document [1], Django looks for and uses if it exists a locale directory in each of the installed apps listed in INSTALLED_APPS. Horizon plugin translations already depend on this mechanism. "horizon", "openstack_dashboard" and "openstack_auth" are all specified in INSTALL_APPS, so we don't need to specify LOCALE_PATHS explicitly.

Even when you have horizon and openstack_dashboard in different places, if translations are stored in horizon/locale and openstack_dashboard/locale, translation should work.

If you would like to have translations in other places, you need to configure LOCALE_PATHS manually.

From the above reason, I mark this bug as Incomplete.

P.S. Anyway, we can drop LOCALE_PATHS from openstack_dashboard/settings.py, but it is just related to this bug.

[1] https://docs.djangoproject.com/en/2.1/topics/i18n/translation/#how-django-discovers-translations

[Gloria Gu (gloria-gu)]

@Akihiro San, thanks for the explanation. I submitted the bug because we observed the issues at oen of our customer sites where they want to translate to zh_TW. It has no issues in my dev environment. Will look into it again...

[Gloria Gu (gloria-gu)]

@Akihiro,

I did some trace...
the code in openstack_dashboard/dashboards/settings/user/forms.py line 109 calls
translation.check_for_language(lang_code)

it calls
/usr/lib/python2.7/site-packages/django/utils/translation/__init__.py 202 check_for_languge(lang_code)

which will call /usr/lib/python2.7/site-packages/django/utils/translation/trans_real.py 421 check_for_language which finds all the path in all_locale_paths() to check the mo files

def all_locale_paths():
    """
    Returns a list of paths to user-provides languages files.
    """
    globalpath = os.path.join(
        os.path.dirname(upath(sys.modules[settings.__module__].__file__)), 'locale')
    return [globalpath] + list(settings.LOCALE_PATHS)

from my trace...I noticed gloabalpath is actually the django path and settings.LOCALE_PATHS are from the setings.py mentioned above....what did I miss here?

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/620676

[Akihiro Motoki (amotoki)]

Gloria,

I think Django loads translations from 'locale' dir of all INSTALLED_APPS but only languages defined in Django are allowed.

If you are trying to support a language which are not known in Django, I have no idea. If so, you should propose a change to Django to support a new language.

[Akihiro Motoki (amotoki)]

As horizon, I believe this is not a bug.

[Akihiro Motoki (amotoki)]

If you have more things to be discussed, feel free to add here. I usually subscribe horizon bug mails.

[Gloria Gu (gloria-gu)]

@Akihiro,

Thanks for look into this.

The language is zh_TW. It is already supported I assume.
It is a problem found by one of our customers. Currently they are using the workaround patch, but they are seeking permanent fix.

As I mentioned in the dev environment ...it is fine for me. But in the production env the install dirs are like the followings:

/opt/stack/venv/horizon-20180814T161452Z/srv/www/openstack-dashboard/openstack_dashboard
/opt/stack/venv/horizon-20180814T161452Z/lib/python2.7/site-packages/horizon/

Then the problem occurs.

I haven't tried your proposed fix, will give it try to see if it fixed our customer's problem.

[Gloria Gu (gloria-gu)]

Tried the fix you have ...it has the same issue that when change language in the settings. Switching language to zh-tw doesn't save the settings. It says it is successful, but NOT saved. It stays at the old language. I switch to Japnese or simplified chinese, it seems to be ok sometimes...but not consistent.

[Akihiro Motoki (amotoki)]

I think we need to split the problem into two parts:

(a) the language change to zh_TW does not work
(b) the translation of zh_TW is not loaded properly

I am not sure you hit both or either of them.

As far as I checked, LOCALES_PATH is not involved in (a).
(a) seems a behavior of Django translation util.

Is my understanding correct?

[Gloria Gu (gloria-gu)]

I think it is because the zh_TW translation doesn't get loaded correctly since Horizon can not find it. Even it is packaged.
If I added my workaround as i mentioned in the description, it works fine.

``
updated settings.py seem to fix the problem, however, still not clear what to do with horizon/locale
Change LOCALE_PATHS = [
    'horizon/locale',
    # 'openstack_dashboard/locale',
    os.path.join(ROOT_PATH, "locale")
]
``

That is what our customers have for workaround the problem at this moment.

[Gloria Gu (gloria-gu)]

I mean django can not find the translation.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/620676
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=1028a65804d3f38c0186caeb39caf26e90d9ec5e
Submitter: Zuul
Branch: master

commit 1028a65804d3f38c0186caeb39caf26e90d9ec5e
Author: Akihiro Motoki <email address hidden>
Date: Thu Nov 29 03:27:34 2018 +0900

    Drop unnecessary LOCALE_PATHS from settings.py

    Django looks for and uses if it exists a locale directory in each of
    the installed apps listed in INSTALLED_APPS [1]. horizon and
    openstack_dashboard are specified in INSTALLED_APPS, so there is no need
    to specify horizon/locale and openstack_dashboard/locale explicitly.
    We can drop them without any side-effect.

    [1] https://docs.djangoproject.com/en/1.11/topics/i18n/translation/#javascript-catalog-view

    Change-Id: Ibe364b2a16894a51fe17411f29a326aef621472c
    Related-Bug: #1804289

[Akihiro Motoki (amotoki)]

Regarding comment #9, it looks like the same issue as bug 1818639.

[Gloria Gu (gloria-gu)]

Thanks @Akihiro, I provided work-around for our customer and then forgot about this. I tried to change invalid to duplicate status, but can not found it. Since it was fixed in https://bugs.launchpad.net/horizon/+bug/1818639, so marked it released.

[Akihiro Motoki (amotoki)]

You can find "Mark as duplicate" at the right top menu.