Source strings

999 Strings
100%
Browse Translate
15,983 Words
100%
108,070 Characters
100%
This translation is being used as source strings within this component.

Strings status

Strings Words Characters
999 15,983 108,070
All strings Browse Translate Zen
999 15,983 108,070
Read-only strings Browse Translate Zen
17 240 1,656
Strings with any failing checks Browse Translate Zen
17 240 1,656
Failing check: Multiple failing checks Browse Translate Zen

Other components

Component Translated Unfinished Unfinished words Unfinished characters Untranslated Checks Suggestions Comments
doc
doc-contributors 100% 6
doc-deploy-guide
doc-reference 100% 32
doc-user 100% 53
releasenotes 100% 5
Browse all components

Summary

Project website opendev.org/openstack/openstack-ansible
Translation process
  • Translations can be made directly.
  • Translation suggestions are turned off.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository local:
Repository branch main
Weblate repository http://weblate.printf.kr/git/openstack-ansible/master/doc-admin/
File mask source/locale/*/LC_MESSAGES/doc-admin.po
Translation file Download doc-admin.pot
Last change Aug. 29, 2026, 1:49 p.m.
Last change made by None
Language English (United States)
Language code en_US
Text direction Left to right
Case sensitivity Case-sensitive
Number of plurals 2
Plural type One/other
Plurals Singular 1
Plural 0, 2, 3, 4, 5, 6, 7, 8, 9, 10, …
Plural formula n != 1
10/16/2026

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 999 15,983 108,070
Translated 100% 999 100% 15,983 100% 108,070
Needs editing 0% 0 0% 0 0% 0
Read-only 100% 999 100% 15,983 100% 108,070
Failing checks 1% 17 1% 240 1% 1,656
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 1,000 changes 0 changes 0 changes
OctNovDecJanFebMarAprMayJunJulAugSep

Quick numbers

15,983
Hosted words
999
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar None

Resource updated
File “doc-admin.pot” was added. 08/29/2026
User avatar None

String added in the repository
Always ensure that the branch is up-to-date and compatible with the rest of your deployment before proceeding.
Always ensure that the branch is up-to-date and compatible with the rest of your deployment before proceeding.
08/29/2026
User avatar None

String added in the repository
This approach is not limited to Nova. You can apply the same method to any other OpenStack service managed by OpenStack-Ansible by overriding its corresponding ``<service>_git_install_branch`` variable.
This approach is not limited to Nova. You can apply the same method to any other OpenStack service managed by OpenStack-Ansible by overriding its corresponding ``<service>_git_install_branch`` variable.
08/29/2026
User avatar None

String added in the repository
After the upgrade to the latest patches in the same branch:
After the upgrade to the latest patches in the same branch:
08/29/2026
User avatar None

String added in the repository
We can verify the version of the service before and after the upgrade (don't forget to load required environment variables):
We can verify the version of the service before and after the upgrade (don't forget to load required environment variables):
08/29/2026
User avatar None

String added in the repository
The playbook will fetch and install the code from the specified branch or commit SHA, applying the latest patches and fixes as defined. Using a pinned SHA ensures consistent versions across all hosts, while following the branch directly will always pull its current HEAD.
The playbook will fetch and install the code from the specified branch or commit SHA, applying the latest patches and fixes as defined. Using a pinned SHA ensures consistent versions across all hosts, while following the branch directly will always pull its current HEAD.
08/29/2026
User avatar None

String added in the repository
And run:
And run:
08/29/2026
User avatar None

String added in the repository
And use that SHA in your configuration to ensure consistent versions across all hosts in your ``user_variables.yml``:
And use that SHA in your configuration to ensure consistent versions across all hosts in your ``user_variables.yml``:
08/29/2026
User avatar None

String added in the repository
So the recommended practice is to take the HEAD commit SHA of the desired stable branch and set it explicitly. To find the latest SHA of the ``stable/2025.1`` branch, you can run (e.g. for Nova):
So the recommended practice is to take the HEAD commit SHA of the desired stable branch and set it explicitly. To find the latest SHA of the ``stable/2025.1`` branch, you can run (e.g. for Nova):
08/29/2026
User avatar None

String added in the repository
Sometimes you may need to apply the latest security patches or bug fixes for a service while remaining on the same stable branch. This can be done by overriding the Git installation branch for that service, which instructs OpenStack-Ansible to pull the most recent code from the branch you are already tracking. But using branches directly as ``<service>_git_install_branch`` is highly discouraged. Every time the playbook is re-run, the service may be upgraded to a newer commit, which can lead to inconsistent versions between hosts (for example, when adding a new compute node later).
Sometimes you may need to apply the latest security patches or bug fixes for a service while remaining on the same stable branch. This can be done by overriding the Git installation branch for that service, which instructs OpenStack-Ansible to pull the most recent code from the branch you are already tracking. But using branches directly as ``<service>_git_install_branch`` is highly discouraged. Every time the playbook is re-run, the service may be upgraded to a newer commit, which can lead to inconsistent versions between hosts (for example, when adding a new compute node later).
08/29/2026
Browse all translation changes