83e7763518
Per the spec [1]: reference/ – any reference information associated with a project that is not covered by one of the above categories. Library projects should place their automatically generated class documentation here. There are a couple of documents that focus on nova internals, but won't necessarily be applicable to user. These are moved here. [1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration Change-Id: I94614c2383329e1fbed60d9c5aca3fab5170ef8f
1.7 KiB
Internationalization
Nova uses the oslo.i18n library to support internationalization. The oslo.i18n library is built on top of gettext and provides functions that are used to enable user-facing strings such as log messages to appear in the appropriate language in different locales.
Nova exposes the oslo.i18n library support via the
nova/i18n.py integration module. This module provides the
functions needed to wrap translatable strings. It provides the
_() wrapper for general user-facing messages (such as ones
that end up in command line responses, or responses over the
network).
One upon a time there was an effort to translate log messages in
OpenStack projects. But starting with the Ocata release these are no
longer being supported. Log messages should not be
translated. Any use of _LI(), _LW(),
_LE(), _LC() are vestigial and will be removed
over time. No new uses of these should be added.
You should use the basic wrapper _() for strings which
are not log messages that are expected to get to an end user:
raise nova.SomeException(_('Invalid service catalogue'))Do not use locals() for formatting messages because: 1.
It is not as clear as using explicit dicts. 2. It could produce hidden
errors during refactoring. 3. Changing the name of a variable causes a
change in the message. 4. It creates a lot of otherwise unused
variables.
If you do not follow the project conventions, your code may cause hacking checks to fail.
The _() function can be imported with :
from nova.i18n import _