horizon 23.4.1.dev25 - en to en_GB translation catalogue (160 entries)

en: "oslo.policy" provides a way to deprecate existing policy rules like renaming rule definitions ("check_str") and renaming rule names. They are defined as part of python codes in back-end services. horizon cannot import python codes of back-end services, so we need a way to restore policies defined by "policy-in-code" including deprecated rules.
en_GB: "oslo.policy" provides a way to deprecate existing policy rules like renaming rule definitions ("check_str") and renaming rule names. They are defined as part of python code in back-end services. Horizon cannot import python code of back-end services, so we need a way to restore policies defined by "policy-in-code" including deprecated rules.

en: A descriptive name used for display purposes. Defaults to the value of ``name`` with the first letter of each word capitalized.
en_GB: A descriptive name used for display purposes. Defaults to the value of ``name`` with the first letter of each word capitalised.

en: A field can only safely define one slug in its ``"switch-on"`` attribute. While switching on multiple fields is possible, the behavior is very hard to predict due to the events being fired from the various switchable fields in order. You generally end up just having it hidden most of the time by accident, so it's not recommended. Instead just add a second field to the form and control the two independently, then merge their results in the form's clean or handle methods at the end.
en_GB: A field can only safely define one slug in its ``"switch-on"`` attribute. While switching on multiple fields is possible, the behaviour is very hard to predict due to the events being fired from the various switchable fields in order. You generally end up just having it hidden most of the time by accident, so it's not recommended. Instead just add a second field to the form and control the two independently, then merge their results in the form's clean or handle methods at the end.

en: A form field used for inline editing of the column. A django forms.Field can be used or django form.Widget can be used.
en_GB: A form field used for inline editing of the column. A Django forms.Field can be used or Django form.Widget can be used.

en: A list of dictionaries containing role names and ids as returned by Keystone.
en_GB: A list of dictionaries containing role names and IDs as returned by Keystone.

en: A list of non-identity service endpoint regions extracted from the service catalog.
en_GB: A list of non-identity service endpoint regions extracted from the service catalogue.

en: A path to a template which contains more complex help text to be displayed alongside the Action's fields. In conjunction with :meth:`~horizon.workflows.Action.get_help_text` method you can customize your help text template to display practically anything.
en_GB: A path to a template which contains more complex help text to be displayed alongside the Action's fields. In conjunction with :meth:`~horizon.workflows.Action.get_help_text` method you can customise your help text template to display practically anything.

en: A second theme is provided by default at ``openstack_dashboard/themes/material/``. When adding new SCSS to horizon, you should check that it does not interfere with the Material theme. Images of how the Material theme should look can be found at https://bootswatch.com/3/paper/. This theme is now configured to run as the alternate theme within Horizon.
en_GB: A second theme is provided by default at ``openstack_dashboard/themes/material/``. When adding new SCSS to Horizon, you should check that it does not interfere with the Material theme. Images of how the Material theme should look can be found at https://bootswatch.com/3/paper/. This theme is now configured to run as the alternate theme within Horizon.

en: A string or a callable which resolves to a url to be used as the link target. You must either define the ``url`` attribute or override the ``get_link_url`` method on the class.
en_GB: A string or a callable which resolves to a URL to be used as the link target. You must either define the ``url`` attribute or override the ``get_link_url`` method on the class.

en: A time margin in seconds to subtract from the real token's validity. An example usage is that the token can be valid once the middleware passed, and invalid (timed-out) during a view rendering and this generates authorization errors during the view rendering. A default margin can be set by the TOKEN_TIMEOUT_MARGIN in the django settings.
en_GB: A time margin in seconds to subtract from the real token's validity. An example usage is that the token can be valid once the middleware passed, and invalid (timed-out) during a view rendering and this generates authorisation errors during the view rendering. A default margin can be set by the TOKEN_TIMEOUT_MARGIN in the django settings.

en: Adding the url
en_GB: Adding the URL

en: After syncing policies from back-end services, you need to check what are changed. If a policy referred by horizon has been changed, you need to check and modify the horizon code base accordingly.
en_GB: After syncing policies from back-end services, you need to check what are changed. If a policy referred by horizon has been changed, you need to check and modify the Horizon code base accordingly.

en: All changes proposed to horizon require two +2 votes from the horizon core reviewers before one of the core reviewers can approve a change by giving "Workflow +1" vote.
en_GB: All changes proposed to Horizon require two +2 votes from the Horizon core reviewers before one of the core reviewers can approve a change by giving "Workflow +1" vote.

en: All other exceptions bubble the stack as normal unless the ``ignore`` argument is passed in as ``True``, in which case only unrecognized errors are bubbled.
en_GB: All other exceptions bubble the stack as normal unless the ``ignore`` argument is passed in as ``True``, in which case only unrecognised errors are bubbled.

en: All view which handles forms in Horiozn should inherit this class. It takes care of all details with processing :class:`~horizon.forms.base.SelfHandlingForm` classes, and modal concerns when the associated template inherits from `horizon/common/_modal_form.html`.
en_GB: All view which handles forms in Horizon should inherit this class. It takes care of all details with processing :class:`~horizon.forms.base.SelfHandlingForm` classes, and modal concerns when the associated template inherits from `horizon/common/_modal_form.html`.

en: An alternative function can be supplied to customize this behavior by specifying a either a URL or a function which returns a URL via the ``"user_home"`` key in ``HORIZON_CONFIG``. Each of these would be valid::
en_GB: An alternative function can be supplied to customise this behaviour by specifying a either a URL or a function which returns a URL via the ``"user_home"`` key in ``HORIZON_CONFIG``. Each of these would be valid::

en: An example of historically limiting, non-free software is Selenium. For a long time, Selenium was only available from the non-free repositories of Debian. The reason was that upstream included some .xpi binaries. These .xpi included some Windows .dll and Linux .so files. Because they could not be rebuilt from the source, all of python-selenium was declared non-free. If we made Horizon build-depends on python-selenium, this would mean Horizon wouldn't be in Debian main anymore (contrib and non-free are *not* considered part of Debian). Recently, the package maintainer of python-selenium decided to remove the .xpi files from python-selenium, and upload it to Debian Experimental (this time, in main, not in non-free). If at some point it is possible for Horizon to use python-selenium (without the non-free .xpi files), then we could run Selenium tests at package build time.
en_GB: An example of historically limiting, non-free software is Selenium. For a long time, Selenium was only available from the non-free repositories of Debian. The reason was that upstream included some .xpi binaries. These .xpi included some Windows .dll and Linux .so files. Because they could not be rebuilt from the source, all of python-selenium was declared non-free. If we made Horizon build-depends on python-selenium, this would mean Horizon wouldn't be in Debian main any more (contrib and non-free are *not* considered part of Debian). Recently, the package maintainer of python-selenium decided to remove the .xpi files from python-selenium, and upload it to Debian Experimental (this time, in main, not in non-free). If at some point it is possible for Horizon to use python-selenium (without the non-free .xpi files), then we could run Selenium tests at package build time.

en: An iterable of CSS classes which will be added when the column's text is displayed as a link. This is left for backward compatibility. Deprecated in favor of the link_attributes attribute. Example: ``link_classes=('link-foo', 'link-bar')``. Defaults to ``None``.
en_GB: An iterable of CSS classes which will be added when the column's text is displayed as a link. This is left for backward compatibility. Deprecated in favour of the link_attributes attribute. Example: ``link_classes=('link-foo', 'link-bar')``. Defaults to ``None``.

en: Another reason to avoid copying a library into Horizon source code is that it might create conflicting licenses. Distributing sources with conflicting licenses in one tarball revokes rights in best case. In the worst case, you could be held legally responsible.
en_GB: Another reason to avoid copying a library into Horizon source code is that it might create conflicting licences. Distributing sources with conflicting licences in one tarball revokes rights in best case. In the worst case, you could be held legally responsible.

en: As the effort of `policy-in-code <https://governance.openstack.org/tc/goals/queens/policy-in-code.html>`__, most OpenStack projects define their default policies in their codes. All projects (except swift) covered by horizon supports "policy-in-code". (Note that swift is an exception as it has its own mechanism to control RBAC.)
en_GB: As the effort of `policy-in-code <https://governance.openstack.org/tc/goals/queens/policy-in-code.html>`__, most OpenStack projects define their default policies in their codes. All projects (except Swift) covered by Horizon supports "policy-in-code". (Note that swift is an exception as it has its own mechanism to control RBAC.)

en: Assuming you implemented ``my_rest_api.py``, you can use a REST client to hit the url directly and test it. There should be many REST clients available on your web browser.
en_GB: Assuming you implemented ``my_rest_api.py``, you can use a REST client to hit the URL directly and test it. There should be many REST clients available on your web browser.

en: Avoid propogating direct exception messages thrown by OpenStack APIs to the UI. It is a precaution against giving obscure or possibly sensitive data to a user. These error messages from the API are also not translatable. Until there is a standard error handling framework implemented by the services which presents clean and translated messages, horizon catches all the exceptions thrown by the API and normalizes them in :func:`horizon.exceptions.handle`.
en_GB: Avoid propagating direct exception messages thrown by OpenStack APIs to the UI. It is a precaution against giving obscure or possibly sensitive data to a user. These error messages from the API are also not translatable. Until there is a standard error handling framework implemented by the services which presents clean and translated messages, Horizon catches all the exceptions thrown by the API and normalises them in :func:`horizon.exceptions.handle`.

en: Because Horizon consumes so many different APIs with completely different ``Exception`` types, it's necessary to have a centralized place for handling exceptions which may be raised.
en_GB: Because Horizon consumes so many different APIs with completely different ``Exception`` types, it's necessary to have a centralised place for handling exceptions which may be raised.

en: Below will cover the more project specific information you need to get started with horizon.
en_GB: Below will cover the more project specific information you need to get started with Horizon.

en: Boolean value to determine whether ajax updating for this row is enabled.
en_GB: Boolean value to determine whether Ajax updating for this row is enabled.

en: By default a :class:`~horizon.Panel` class looks for a ``urls.py`` file in the same directory as ``panel.py`` to include in the rollup of url patterns from panels to dashboards to Horizon, resulting in a wholly extensible, configurable URL structure.
en_GB: By default a :class:`~horizon.Panel` class looks for a ``urls.py`` file in the same directory as ``panel.py`` to include in the rollup of URL patterns from panels to dashboards to Horizon, resulting in a wholly extensible, configurable URL structure.

en: By default if multiselect enabled return True. You can remove the checkbox after an ajax update here if required.
en_GB: By default if multiselect enabled return True. You can remove the checkbox after an Ajax update here if required.

en: Centralized error handling for Horizon.
en_GB: Centralised error handling for Horizon.

en: ChoiceInput class from django 1.10.7 codebase
en_GB: ChoiceInput class from Django 1.10.7 codebase

en: Clean up the auth url to extract the exact Keystone URL
en_GB: Clean up the auth URL to extract the exact Keystone URL

en: Common function for getting the permission froms arg
en_GB: Common function for getting the permission from arg

en: Compile the catalog
en_GB: Compile the catalogue

en: Current behavior is changed
en_GB: Current behaviour is changed

en: Determine if agiven filter field should be used as an API filter.
en_GB: Determine if a given filter field should be used as an API filter.

en: Django looks for translation message catalogs from each path specified in ``INSTALLED_APPS`` [#]_.
en_GB: Django looks for translation message catalogues from each path specified in ``INSTALLED_APPS`` [#]_.

en: Django provides a lot of settings and it is not practical to cover all in horizon. Only Django settings which horizon explicitly set will be defined in a dedicated python module.
en_GB: Django provides a lot of settings and it is not practical to cover all in horizon. Only Django settings which horizon explicitly set will be defined in a dedicated Python module.

en: Exception classes such as NotAuthorized, NotFound and Http302 are caught and handles them gracefully.
en_GB: Exception classes such as NotAuthorised, NotFound and HTTP302 are caught and handles them gracefully.

en: Fix up the auth url if an invalid or no version prefix was given.
en_GB: Fix up the auth URL if an invalid or no version prefix was given.

en: For client-side translation, Django embeds a corresponding Django message catalog. Javascript code on the client can use this catalog to do string replacement similar to how server-side translation works.
en_GB: For client-side translation, Django embeds a corresponding Django message catalog. Javascript code on the client can use this catalogue to do string replacement similar to how server-side translation works.

en: Forms Javascript
en_GB: Forms JavaScript

en: GUI supports for most OpenStack projects are achieved via horizon plugins. The horizon core reviewer team has responsibility to help horizon plugin teams from the perspective of horizon related changes as the framework, for example, Django version bump, testing improvements, plugin interface changes in horizon and so on. A member of the team is expected to send and review patches related to such changes.
en_GB: GUI supports for most OpenStack projects are achieved via horizon plugins. The Horizon core reviewer team has responsibility to help Horizon plugin teams from the perspective of Horizon related changes as the framework, for example, Django version bump, testing improvements, plugin interface changes in Horizon and so on. A member of the team is expected to send and review patches related to such changes.

en: Helping horizon plugin maintenances
en_GB: Helping Horizon plugin maintenances

en: Hook to allow customization of the message returned to the user.
en_GB: Hook to allow customisation of the message returned to the user.

en: Hook to customize how the workflow context is passed to the action.
en_GB: Hook to customise how the workflow context is passed to the action.

en: Horizon connects to the rest of OpenStack via a Keystone service catalog. By default Horizon looks for an endpoint at ``http://localhost/identity/v3``; this can be customised by modifying the ``OPENSTACK_HOST`` and ``OPENSTACK_KEYSTONE_URL`` values in ``openstack_dashboard/local/local_settings.py``
en_GB: Horizon connects to the rest of OpenStack via a Keystone service catalogue. By default Horizon looks for an endpoint at ``http://localhost/identity/v3``; this can be customised by modifying the ``OPENSTACK_HOST`` and ``OPENSTACK_KEYSTONE_URL`` values in ``openstack_dashboard/local/local_settings.py``

en: Horizon includes a componentized API for programmatically creating tables in the UI. Why would you want this? It means that every table renders correctly and consistently, table-level and row-level actions all have a consistent API and appearance, and generally you don't have to reinvent the wheel or copy-and-paste every time you need a new table!
en_GB: Horizon includes a componentised API for programmatically creating tables in the UI. Why would you want this? It means that every table renders correctly and consistently, table-level and row-level actions all have a consistent API and appearance, and generally you don't have to reinvent the wheel or copy-and-paste every time you need a new table!

en: Horizon provides a :class:`~horizon.forms.base.SelfHandlingForm` class which simplifies some of the details involved in creating a form. Our form will derive from this class, adding a character field to allow the user to specify a name for the snapshot, and handling the successful closure of the form by calling the nova api to create the snapshot.
en_GB: Horizon provides a :class:`~horizon.forms.base.SelfHandlingForm` class which simplifies some of the details involved in creating a form. Our form will derive from this class, adding a character field to allow the user to specify a name for the snapshot, and handling the successful closure of the form by calling the Nova API to create the snapshot.

en: Horizon ships with some very useful base form classes, form fields, class-based views, and javascript helpers which streamline most of the common tasks related to form handling.
en_GB: Horizon ships with some very useful base form classes, form fields, class-based views, and JavaScript helpers which streamline most of the common tasks related to form handling.

en: Horizon's policy enforcement builds on the oslo_policy engine. The basis of which is ``openstack_auth/policy.py``. Services in OpenStack use the oslo policy engine to define policy rules to limit access to APIs based primarily on role grants and resource ownership.
en_GB: Horizon's policy enforcement builds on the oslo_policy engine. The basis of which is ``openstack_auth/policy.py``. Services in OpenStack use the Oslo policy engine to define policy rules to limit access to APIs based primarily on role grants and resource ownership.

en: How to Utilize RBAC
en_GB: How to Utilise RBAC

en: If keystone_provider is given then we switch the user to the keystone provider using K2K federation. Otherwise if keystone_provider is None then we switch the user back to the Identity Provider Keystone which a non federated token auth will be used.
en_GB: If keystone_provider is given then we switch the user to the Keystone provider using K2K federation. Otherwise if keystone_provider is None then we switch the user back to the Identity Provider Keystone which a non federated token auth will be used.

en: If you have no plans to add AngularJS to your plugin, you may skip this section. In the tutorial below, we will show you how to customize your panel using Angular.
en_GB: If you have no plans to add AngularJS to your plugin, you may skip this section. In the tutorial below, we will show you how to customise your panel using Angular.

en: If you're looking for some smaller, please look through the list of bugs and find what you think you can work on. If you are not sure the status of a bug feel free to ask to the horizon team. We can help you. Note that we recently do not maintain 'low-hanging-fruit' tag and some of them with this tag are not simple enough.
en_GB: If you're looking for some smaller, please look through the list of bugs and find what you think you can work on. If you are not sure the status of a bug feel free to ask to the Horizon team. We can help you. Note that we recently do not maintain 'low-hanging-fruit' tag and some of them with this tag are not simple enough.

en: In Keystone V3, region has been deprecated in favor of region_id.
en_GB: In Keystone V3, region has been deprecated in favour of region_id.

en: In general, horizon deliverables follow the `cycle-with-intermediary <https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary>`__ release model.
en_GB: In general, Horizon deliverables follow the `cycle-with-intermediary <https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary>`__ release model.

en: In order to make ``My Dashboard`` show up along with the existing dashboards like ``Project`` or ``Admin`` on horizon, you need to create a file called ``_50_mydashboard.py`` under ``openstack_dashboard/enabled`` and add the following::
en_GB: In order to make ``My Dashboard`` show up along with the existing dashboards like ``Project`` or ``Admin`` on Horizon, you need to create a file called ``_50_mydashboard.py`` under ``openstack_dashboard/enabled`` and add the following::

en: In this example, we are listening for events generated by the wizard and the user panel. We also emit a custom event that other controllers can register to when favorite color changes.
en_GB: In this example, we are listening for events generated by the wizard and the user panel. We also emit a custom event that other controllers can register to when favourite colour changes.

en: In this scenario you may need to submit a secondary patch to address test coverage for another function within horizon to ensure tests rise above the coverage threshold and your original patch can pass the necessary tests.
en_GB: In this scenario you may need to submit a secondary patch to address test coverage for another function within Horizon to ensure tests rise above the coverage threshold and your original patch can pass the necessary tests.

en: It is detremined based on the dictionary of column name to status mappings passed in.
en_GB: It is determined based on the dictionary of column name to status mappings passed in.

en: It is possible for tests to fail on your patch due to the npm-run-test not passing the minimum threshold. This is not necessarily related directly to the functions in the patch that have failed, but more that there are not enough tests across horizon that are related to your patch.
en_GB: It is possible for tests to fail on your patch due to the npm-run-test not passing the minimum threshold. This is not necessarily related directly to the functions in the patch that have failed, but more that there are not enough tests across Horizon that are related to your patch.

en: Keep document reflows to a minimum. DOM manipulation is expensive, and can become a performance issue. If you are accessing the DOM, make sure that you are doing it in the most optimized way. One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.
en_GB: Keep document reflows to a minimum. DOM manipulation is expensive, and can become a performance issue. If you are accessing the DOM, make sure that you are doing it in the most optimised way. One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.

en: Lastly, this code introduces the concept of error handling in horizon. The :func:`horizon.exceptions.handle` function is a centralized error handling mechanism that takes all the guess-work and inconsistency out of dealing with exceptions from the API. Use it everywhere.
en_GB: Lastly, this code introduces the concept of error handling in horizon. The :func:`horizon.exceptions.handle` function is a centralised error handling mechanism that takes all the guess-work and inconsistency out of dealing with exceptions from the API. Use it everywhere.

en: Load the row's data and initialize all the cells in the row.
en_GB: Load the row's data and initialise all the cells in the row.

en: Members of this gerrit group are responsible for maintaining stable branches. The members are expected to understand `the stable branch policy <https://docs.openstack.org/project-team-guide/stable-branches.html>`__. Most members overlaps with the core reviewer team but being a core reviewer is not a requirement for being a member of the stable maintenance team. Folks who would like to be a member of this team is recommended to express how they understand the stable branch policy in reviews.
en_GB: Members of this Gerrit group are responsible for maintaining stable branches. The members are expected to understand `the stable branch policy <https://docs.openstack.org/project-team-guide/stable-branches.html>`__. Most members overlaps with the core reviewer team but being a core reviewer is not a requirement for being a member of the stable maintenance team. Folks who would like to be a member of this team is recommended to express how they understand the stable branch policy in reviews.

en: Members of this launchpad group can do all things in the horizon launchpad such as defining series and milestones. This group is included to the bug supervisor team.
en_GB: Members of this launchpad group can do all things in the Horizon launchpad such as defining series and milestones. This group is included to the bug supervisor team.

en: Note that `oslopolicy-sample-generator` does not output deprecated rules in a structured way, so we prepare a dedicated script for this purpose in the horizon repo.
en_GB: Note that `oslopolicy-sample-generator` does not output deprecated rules in a structured way, so we prepare a dedicated script for this purpose in the Horizon repo.

en: Note that involvements in more works in horizon plugins are up to individuals but it would be nice to be involved if you have time :)
en_GB: Note that involvements in more works in Horizon plugins are up to individuals but it would be nice to be involved if you have time :)

en: Once marked, we can then run ``tox -e manage -- extract_messages``, which searches the codebase for these markers and extracts them into a Portable Object Template (POT) file. In horizon, we extract from both the ``horizon`` folder and the ``openstack_dashboard`` folder. We use the AngularJS extractor for JavaScript and HTML files and the Django extractor for Python and Django templates; both extractors are Babel plugins.
en_GB: Once marked, we can then run ``tox -e manage -- extract_messages``, which searches the codebase for these markers and extracts them into a Portable Object Template (POT) file. In Horizon, we extract from both the ``horizon`` folder and the ``openstack_dashboard`` folder. We use the AngularJS extractor for JavaScript and HTML files and the Django extractor for Python and Django templates; both extractors are Babel plugins.

en: Once the upper-constraints.txt patch merges, you should propose a patch to global-requirements which bumps the minimum version of the package up to the upper-constraints version so that deployers / packagers who don't honor upper-constraints still get compatible versions of the packages.
en_GB: Once the upper-constraints.txt patch merges, you should propose a patch to global-requirements which bumps the minimum version of the package up to the upper-constraints version so that deployers / packagers who don't honour upper-constraints still get compatible versions of the packages.

en: Open <dev_server_ip:port>/jasmine in a browser. The development server can be run with ``tox -e runserver`` from the horizon root directory.
en_GB: Open <dev_server_ip:port>/jasmine in a browser. The development server can be run with ``tox -e runserver`` from the Horizon root directory.

en: OpenStack infra scripts assumes translation message catalogs are placed under ``<modulename>/locale`` (for example ``myplugin/locale``).
en_GB: OpenStack infra scripts assumes translation message catalogues are placed under ``<modulename>/locale`` (for example ``myplugin/locale``).

en: Optional message for providing an appropriate help text for the horizon user.
en_GB: Optional message for providing an appropriate help text for the Horizon user.

en: Order of precedence: 1. 'services_region' cookie value 2. Matching endpoint in DEFAULT_SERVICE_REGIONS 3. '*' key in DEFAULT_SERVICE_REGIONS 4. First valid region from catalog
en_GB: Order of precedence: 1. 'services_region' cookie value 2. Matching endpoint in DEFAULT_SERVICE_REGIONS 3. '*' key in DEFAULT_SERVICE_REGIONS 4. First valid region from catalogue

en: Policy rules are defined in ``horizon/openstack_dashboard/conf/``. Permissions are inherited from Keystone and take either the form 'openstack.roles.role_name' or 'openstack.services.service_name' for the user's roles in keystone and the services in their service catalog.
en_GB: Policy rules are defined in ``horizon/openstack_dashboard/conf/``. Permissions are inherited from Keystone and take either the form 'openstack.roles.role_name' or 'openstack.services.service_name' for the user's roles in keystone and the services in their service catalogue.

en: Possible client ip address
en_GB: Possible client IP address

en: Removals and deprecations of back-end feature supports basically follows `the standard deprecation policy <https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html>`__ defined by the technical committee, but there are some notes. Deprecations in back-end services are applied to corresponding horizon features automatically and it is allowed to drop some feature from horizon without an explicit deprecation.
en_GB: Removals and deprecations of back-end feature supports basically follows `the standard deprecation policy <https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html>`__ defined by the technical committee, but there are some notes. Deprecations in back-end services are applied to corresponding Horizon features automatically and it is allowed to drop some feature from Horizon without an explicit deprecation.

en: Return a copy of url with all occurrences of old replaced by new in the url path.  If the optional argument count is given, only the first count occurrences are replaced.
en_GB: Return a copy of URL with all occurrences of old replaced by new in the URL path.  If the optional argument count is given, only the first count occurrences are replaced.

en: Return a copy of url with replaced path.
en_GB: Return a copy of URL with replaced path.

en: Return client ip address using SECURE_PROXY_ADDR_HEADER variable.
en_GB: Return client IP address using SECURE_PROXY_ADDR_HEADER variable.

en: Return the keystone endpoint for initiating WebSSO.
en_GB: Return the Keystone endpoint for initiating WebSSO.

en: Returns a css class for the status of the row based on ``status``.
en_GB: Returns a CSS class for the status of the row based on ``status``.

en: Returns a css class name determined by the status value.
en_GB: Returns a CSS class name determined by the status value.

en: Returns a memoized list of tenants this user may access.
en_GB: Returns a memoised list of tenants this user may access.

en: Returns list of unique region name values in service catalog.
en_GB: Returns list of unique region name values in service catalogue.

en: Returns the initialized tab group for this view.
en_GB: Returns the initialised tab group for this view.

en: Run the following command after installing a corresponding project. You need to run it for keystone, nova, cinder, neutron, glance.
en_GB: Run the following command after installing a corresponding project. You need to run it for Keystone, Nova, Cinder, Neutron, Glance.

en: Run the following commands after installing a corresponding project. You need to run it for keystone, nova, cinder, neutron, glance.
en_GB: Run the following commands after installing a corresponding project. You need to run it for Keystone, Nova, Cinder, Neutron, Glance.

en: Runs the Python unit tests against the current default version of Django with Python 3.7 environment. Check ``requirements.txt`` in horizon repository to know which version of Django is actually used.
en_GB: Runs the Python unit tests against the current default version of Django with Python 3.7 environment. Check ``requirements.txt`` in Horizon repository to know which version of Django is actually used.

en: Should return a booleanvalue or raise :class:`~horizon.exceptions.WorkflowValidationError`.
en_GB: Should return a boolean value or raise :class:`~horizon.exceptions.WorkflowValidationError`.

en: So we have a table, ready to receive our data. We could go straight to a view from here, but in this case we're also going to use horizon's :class:`~horizon.tabs.TabGroup` class.
en_GB: So we have a table, ready to receive our data. We could go straight to a view from here, but in this case we're also going to use Horizon's :class:`~horizon.tabs.TabGroup` class.

en: Style guidelines for CSS are currently quite minimal. Do your best to make the code readable and well-organized. Two spaces are preferred for indentation so as to match both the JavaScript and HTML files.
en_GB: Style guidelines for CSS are currently quite minimal. Do your best to make the code readable and well-organised. Two spaces are preferred for indentation so as to match both the JavaScript and HTML files.

en: SubWidget class from django 1.10.7 codebase
en_GB: SubWidget class from Django 1.10.7 codebase

en: Switches the user's keystone provider using K2K Federation
en_GB: Switches the user's Keystone provider using K2K Federation

en: Table cells can be easily upgraded with in-line editing. With use of django.form.Field, we are able to run validations of the field and correctly parse the data. The updating process is fully encapsulated into table functionality, communication with the server goes through AJAX in JSON format. The javascript wrapper for inline editing allows each table cell that has in-line editing available to:
en_GB: Table cells can be easily upgraded with in-line editing. With use of django.form.Field, we are able to run validations of the field and correctly parse the data. The updating process is fully encapsulated into table functionality, communication with the server goes through AJAX in JSON format. The JavaScript wrapper for inline editing allows each table cell that has in-line editing available to:

en: The "horizon" directory
en_GB: The "Horizon" directory

en: The Django message catalog is injected into the front-end. The gettext function is available as a global function so you can just use it directly. If you are writing AngularJS code, we prefer that you use the gettext service, which is essentially a wrapper around the gettext function.
en_GB: The Django message catalogue is injected into the front-end. The gettext function is available as a global function so you can just use it directly. If you are writing AngularJS code, we prefer that you use the gettext service, which is essentially a wrapper around the gettext function.

en: The ``statuses`` parameter is passed in as a dictionary mapping column names to their statuses in order to allow this function to be overridden in such a way as to weight one column's status over another should that behavior be desired.
en_GB: The ``statuses`` parameter is passed in as a dictionary mapping column names to their statuses in order to allow this function to be overridden in such a way as to weight one column's status over another should that behaviour be desired.

en: The annotations in the example above are guaranteed to work. However, not all of the angular-gettext annotations are supported because we wrote our own custom babel extractor. If you need support for the annotations, ask on IRC in the **#openstack-horizon** room or report a bug. Also note that you should avoid embedding HTML fragments in your texts because it makes it harder to translate. Use your best judgement if you absolutely need to include HTML.
en_GB: The annotations in the example above are guaranteed to work. However, not all of the angular-gettext annotations are supported because we wrote our own custom Babel extractor. If you need support for the annotations, ask on IRC in the **#openstack-horizon** room or report a bug. Also note that you should avoid embedding HTML fragments in your texts because it makes it harder to translate. Use your best judgement if you absolutely need to include HTML.

en: The code below is just for example purposes, and may not be current in horizon. Ellipses (...) are used to represent code that has been removed for the sake of brevity.
en_GB: The code below is just for example purposes, and may not be current in Horizon. Ellipses (...) are used to represent code that has been removed for the sake of brevity.

en: The core reviewer team is responsible for the horizon development in the master branch from various perspective. See :doc:`core-reviewers` for more detail.
en_GB: The core reviewer team is responsible for the Horizon development in the master branch from various perspective. See :doc:`core-reviewers` for more detail.

en: The coverage reports may be found in the 'cover' directory. There's a subdirectory for horizon and openstack_dashboard, and then under a directory for the browser used to run the tests you should find an ``index.html``. This can then be viewed to see the coverage details.
en_GB: The coverage reports may be found in the 'cover' directory. There's a subdirectory for Horizon and openstack_dashboard, and then under a directory for the browser used to run the tests you should find an ``index.html``. This can then be viewed to see the coverage details.

en: The current naming convention is random, so it sounds less reasonable to use the same name for oslo.config. oslo.config and python ini-based configuration mechanism provide a concept of category and there is no reason to use it. As category name, the categories of :doc:`/configuration/settings` (like keystone, glance) will be honored.
en_GB: The current naming convention is random, so it sounds less reasonable to use the same name for oslo.config. oslo.config and python ini-based configuration mechanism provide a concept of category and there is no reason to use it. As category name, the categories of :doc:`/configuration/settings` (like Keystone, Glance) will be honoured.

en: The default behavior is to ignore POST data.
en_GB: The default behaviour is to ignore POST data.

en: The default behavior is to return ``True`` for all cases.
en_GB: The default behaviour is to return ``True`` for all cases.

en: The file structure for your plugin type will be different depending on your needs. Your plugin can be categorized into two types:
en_GB: The file structure for your plugin type will be different depending on your needs. Your plugin can be categorised into two types:

en: The following is a complex example of how data is exchanged between urls, views, workflows and templates:
en_GB: The following is a complex example of how data is exchanged between URLs, views, workflows and templates:

en: The horizon PTL is expected to coordinate and encourage the core reviewer team and contributors for the success. The expectations for the core reviewer team is documented at :doc:`policies/core-reviewers` and the PTL would play an important role in this.
en_GB: The Horizon PTL is expected to coordinate and encourage the core reviewer team and contributors for the success. The expectations for the core reviewer team is documented at :doc:`policies/core-reviewers` and the PTL would play an important role in this.

en: The horizon core reviewer team is responsible for many aspects of the horizon project. These include, but are not limited to:
en_GB: The Horizon core reviewer team is responsible for many aspects of the Horizon project. These include, but are not limited to:

en: The horizon team has a weekly meeting which covers all things related to the horizon project like announcements, project priorities, community goals, bugs and so on.
en_GB: The Horizon team has a weekly meeting which covers all things related to the horizon project like announcements, project priorities, community goals, bugs and so on.

en: The method is largely meant for internal use, but if you want to override it to provide custom behavior you can do so at your own risk.
en_GB: The method is largely meant for internal use, but if you want to override it to provide custom behaviour you can do so at your own risk.

en: The name for this column which should be used for display purposes. Defaults to the value of ``transform`` with the first letter of each word capitalized if the ``transform`` is not callable, otherwise it defaults to an empty string (``""``).
en_GB: The name for this column which should be used for display purposes. Defaults to the value of ``transform`` with the first letter of each word capitalised if the ``transform`` is not callable, otherwise it defaults to an empty string (``""``).

en: The related files in the horizon codebase are:
en_GB: The related files in the Horizon codebase are:

en: The returned classes are determied based on the workflow characteristics.
en_GB: The returned classes are determined based on the workflow characteristics.

en: The returned display form is highly recommended to be a complete action name with a form of a transitive verb and an object noun. Each word is capitalized and the string should be marked as translatable.
en_GB: The returned display form is highly recommended to be a complete action name with a form of a transitive verb and an object noun. Each word is capitalised and the string should be marked as translatable.

en: The row's data is provided either at initialization or as an argument to this function.
en_GB: The row's data is provided either at initialisation or as an argument to this function.

en: The second "sed" command is to comment out rules for rule renames. `oslopolicy-sample-generator` does not comment out them, but they are unnecessary in horizon usage. A single renaming rule can map to multiple rules, so it does not work as-is. In addition, they trigger deprecation warnings in horizon log if these sample files are used in horizon as-is. Thus, we comment them out by default.
en_GB: The second "sed" command is to comment out rules for rule renames. `oslopolicy-sample-generator` does not comment out them, but they are unnecessary in Horizon usage. A single renaming rule can map to multiple rules, so it does not work as-is. In addition, they trigger deprecation warnings in Horizon log if these sample files are used in Horizon as-is. Thus, we comment them out by default.

en: The slug of the step which should initially be active when the workflow is rendered. This can be passed in upon initialization of the workflow, or set anytime after initialization but before calling either ``get_entry_point`` or ``render``.
en_GB: The slug of the step which should initially be active when the workflow is rendered. This can be passed in upon initialisation of the workflow, or set anytime after initialisation but before calling either ``get_entry_point`` or ``render``.

en: The third way to add a role based check is in javascript files. Use the method 'ifAllowed()' in file 'openstack_dashboard.static.app.core.policy.service.js'. The method takes a list of actions, similar format with the :attr:`~horizon.tables.Action.policy_rules` attribute detailed above. An Example looks like::
en_GB: The third way to add a role based check is in JavaScript files. Use the method 'ifAllowed()' in file 'openstack_dashboard.static.app.core.policy.service.js'. The method takes a list of actions, similar format with the :attr:`~horizon.tables.Action.policy_rules` attribute detailed above. An Example looks like::

en: Then look at the generated release notes files in releasenotes/build/html in your favorite browser.
en_GB: Then look at the generated release notes files in releasenotes/build/html in your favourite browser.

en: There are lots of pre-built class-based views in horizon. We try to provide the starting points for all the common combinations of components.
en_GB: There are lots of pre-built class-based views in Horizon. We try to provide the starting points for all the common combinations of components.

en: There is the "On Demand Agenda" section at the end of the meeting, where anyone can add a topic to discuss with the team. It is suggested to add such topic to the On-Demand agenda in the "Weekly meeting" in `horizon release priority etherpad <https://etherpad.opendev.org/p/horizon-release-priorities>`__.
en_GB: There is the "On Demand Agenda" section at the end of the meeting, where anyone can add a topic to discuss with the team. It is suggested to add such topic to the On-Demand agenda in the "Weekly meeting" in `horizon release priority Etherpad <https://etherpad.opendev.org/p/horizon-release-priorities>`__.

en: This file contains contents you want to display to the user. We will provide a simple example of a step that asks for your favorite color. The most important thing to note here is the reference to our controller via the ``ng-controller`` directive. This is essentially the link to our controller.
en_GB: This file contains contents you want to display to the user. We will provide a simple example of a step that asks for your favourite colour. The most important thing to note here is the reference to our controller via the ``ng-controller`` directive. This is essentially the link to our controller.

en: This guide is a work in progress. It has been uploaded to encourage faster reviewing and code development in Angular, and to help the community standardize on a set of guidelines. There are notes inline on sections that are likely to change soon, and the docs will be updated promptly after any changes.
en_GB: This guide is a work in progress. It has been uploaded to encourage faster reviewing and code development in Angular, and to help the community standardise on a set of guidelines. There are notes inline on sections that are likely to change soon, and the docs will be updated promptly after any changes.

en: This is a special flavor of FileField which is meant to be used in cases when instead of uploading file to Django it should be uploaded to some external location, while the form validation is done as usual. It should be paired with ExternalUploadMeta metaclass embedded into the Form class.
en_GB: This is a special flavour of FileField which is meant to be used in cases when instead of uploading file to Django it should be uploaded to some external location, while the form validation is done as usual. It should be paired with ExternalUploadMeta metaclass embedded into the Form class.

en: This is the entry point into our plugin. We hook into an existing module via the run block which is executed after the module has been initialized. All we need to do is inject it as a dependency and then use the methods provided in the extensible service to override or modify steps. In this example, we are going to prepend our custom step so that it will show up as the first step in the wizard.
en_GB: This is the entry point into our plugin. We hook into an existing module via the run block which is executed after the module has been initialised. All we need to do is inject it as a dependency and then use the methods provided in the extensible service to override or modify steps. In this example, we are going to prepend our custom step so that it will show up as the first step in the wizard.

en: This is the reverse of what "contribute" does to make the action outputs sane for the workflow. Changes to the context are not saved globally here. They are localized to the action.
en_GB: This is the reverse of what "contribute" does to make the action outputs sane for the workflow. Changes to the context are not saved globally here. They are localised to the action.

en: This method can be used to customize where a user is sent when they log in, etc. By default it returns the value of :meth:`get_absolute_url`.
en_GB: This method can be used to customise where a user is sent when they log in, etc. By default it returns the value of :meth:`get_absolute_url`.

en: This page collects basic policies on horizon development.
en_GB: This page collects basic policies on Horizon development.

en: This section serves as a basic introduction to writing your own panel for horizon, using AngularJS. A panel may be included with the plugin system, or it may be part of the upstream horizon project.
en_GB: This section serves as a basic introduction to writing your own panel for horizon, using AngularJS. A panel may be included with the plugin system, or it may be part of the upstream Horizon project.

en: This stores variables related to Keystone2Keystone federation. This function gets skipped if there are no Keystone service providers. An unscoped token to the identity provider keystone gets stored so that it can be used to do federated login into the service providers when switching keystone providers. The settings file can be configured to set the display name of the local (identity provider) keystone by setting KEYSTONE_PROVIDER_IDP_NAME. The KEYSTONE_PROVIDER_IDP_ID settings variable is used for comparison against the service providers. It should not conflict with any of the service provider ids.
en_GB: This stores variables related to Keystone2Keystone federation. This function gets skipped if there are no Keystone service providers. An unscoped token to the identity provider Keystone gets stored so that it can be used to do federated login into the service providers when switching Keystone providers. The settings file can be configured to set the display name of the local (identity provider) Keystone by setting KEYSTONE_PROVIDER_IDP_NAME. The KEYSTONE_PROVIDER_IDP_ID settings variable is used for comparison against the service providers. It should not conflict with any of the service provider ids.

en: This tutorial covers how to add a more complex action to a table, one that requires an action and form definitions, as well as changes to the view, urls, and table.
en_GB: This tutorial covers how to add a more complex action to a table, one that requires an action and form definitions, as well as changes to the view, URLs, and table.

en: This tutorial covers how to use the various components in horizon to build an example dashboard and a panel with a tab which has a table containing data from the back end.
en_GB: This tutorial covers how to use the various components in Horizon to build an example dashboard and a panel with a tab which has a table containing data from the back end.

en: Those urls are automatically constructed based on the registered Horizon apps. If a different URL structure is desired it can be constructed by hand.
en_GB: Those URLs are automatically constructed based on the registered Horizon apps. If a different URL structure is desired it can be constructed by hand.

en: To address the above issue, horizon adopts the following two-step approach:
en_GB: To address the above issue, Horizon adopts the following two-step approach:

en: To decipher where tests are failing it may be useful to use Jasmine in the browser to run individual tests to see where the tests are specifically breaking. To do this, navigate to your local horizon in the browser and add '/jasmine' to the end of the url. e.g: 'http://localhost:8000/jasmine'. Once you have the jasmine report you may click on the title of an individual test to re-run just that test. From here, you can also use chrome dev tools or similar to set breakpoints in the code by accessing the 'Sources' tab and clicking on lines of code where you wish to break the code. This will then show you the exact places where the code breaks.
en_GB: To decipher where tests are failing it may be useful to use Jasmine in the browser to run individual tests to see where the tests are specifically breaking. To do this, navigate to your local Horizon in the browser and add '/jasmine' to the end of the url. e.g: 'http://localhost:8000/jasmine'. Once you have the Jasmine report you may click on the title of an individual test to re-run just that test. From here, you can also use Chrome Dev tools or similar to set breakpoints in the code by accessing the 'Sources' tab and clicking on lines of code where you wish to break the code. This will then show you the exact places where the code breaks.

en: To make your strings translatable, you need to mark it so that horizon can locate and extract it into a POT file. When a user from another locale visits your page, your string is replaced with the correct translated version.
en_GB: To make your strings translatable, you need to mark it so that Horizon can locate and extract it into a POT file. When a user from another locale visits your page, your string is replaced with the correct translated version.

en: To summarize which policies are removed or added, a convenient tool is provided:
en_GB: To summarise which policies are removed or added, a convenient tool is provided:

en: Token object provides a consistent interface for accessing the keystone token information and service catalog.
en_GB: Token object provides a consistent interface for accessing the keystone token information and service catalogue.

en: Translated message catalog files (PO files) are placed under this directory.
en_GB: Translated message catalogue files (PO files) are placed under this directory.

en: Translation (Internationalization and Localization)
en_GB: Translation (Internationalisation and Localisation)

en: Update default policy-in-code rules in horizon for all backend services like cinder/glance/keystone/neutron/nova. For more information on how to update these policy rules see the :doc:`/contributor/topics/policy`.
en_GB: Update default policy-in-code rules in Horizon for all backend services like Cinder/Glance/Keystone/Neutron/Nova. For more information on how to update these policy rules see the :doc:`/contributor/topics/policy`.

en: Use proper grammar, spelling, capitalization and punctuation at all times.
en_GB: Use proper grammar, spelling, capitalisation and punctuation at all times.

en: Version(s) of related components (at least horizon version is required)
en_GB: Version(s) of related components (at least Horizon version is required)

en: We must add the url for our new view.  Open the ``urls.py`` file under the ``mypanel`` directory and add the following as a new url pattern::
en_GB: We must add the URL for our new view.  Open the ``urls.py`` file under the ``mypanel`` directory and add the following as a new URL pattern::

en: We must once again run horizon to verify our dashboard is working::
en_GB: We must once again run Horizon to verify our dashboard is working::

en: We will convert the object id and ``lookup`` to unicode before comparison.
en_GB: We will convert the object id and ``lookup`` to Unicode before comparison.

en: What you've learned here is the fundamentals of how to write interfaces for your own project based on the components horizon provides.
en_GB: What you've learned here is the fundamentals of how to write interfaces for your own project based on the components Horizon provides.

en: When adding code to horizon, consider whether it is dashboard-specific or should be broken out as a reusable utility or widget.
en_GB: When adding code to Horizon, consider whether it is dashboard-specific or should be broken out as a reusable utility or widget.

en: When writing a new feature, think about writing unit tests to verify the behavior step-by-step as you write the feature. Every time you'd go to run your code by hand and verify it manually, think "could I write a test to do this instead?". That way when the feature is done and you're ready to commit it you've already got a whole set of tests that are more thorough than anything you'd write after the fact.
en_GB: When writing a new feature, think about writing unit tests to verify the behaviour step-by-step as you write the feature. Every time you'd go to run your code by hand and verify it manually, think "could I write a test to do this instead?". That way when the feature is done and you're ready to commit it you've already got a whole set of tests that are more thorough than anything you'd write after the fact.

en: You can choose to customize your panel by providing your own scss. Be sure to include it in your enabled file via the ``ADD_SCSS_FILES`` setting.
en_GB: You can choose to customise your panel by providing your own scss. Be sure to include it in your enabled file via the ``ADD_SCSS_FILES`` setting.

en: ``LOGGING`` setting is long enough. Python now recommend to configure logging using python dict directly, but from operator/packager perspective the legacy style of using the ini format sounds reasonable. The ini format is also used in other OpenStack projects too. In this effort, I propose to use the logging configuration via the ini format file and specify the logging conf file in a oslo.config option
en_GB: ``LOGGING`` setting is long enough. Python now recommend to configure logging using Python dict directly, but from operator/packager perspective the legacy style of using the ini format sounds reasonable. The ini format is also used in other OpenStack projects too. In this effort, I propose to use the logging configuration via the ini format file and specify the logging conf file in a oslo.config option

en: ``N`` release of horizon supports ``N`` and ``N-1`` releases of back-end OpenStack services (like nova, cinder, neutron and so on). This allows operators to upgrade horizon separately from other OpenStack services.
en_GB: ``N`` release of Horizon supports ``N`` and ``N-1`` releases of back-end OpenStack services (like Nova, Cinder, Neutron and so on). This allows operators to upgrade Horizon separately from other OpenStack services.

en: ``ServiceCatalog`` is fetched from Keystone.
en_GB: ``ServiceCatalogue`` is fetched from Keystone.

en: ``UNAUTHORIZED``: Errors resulting from authentication or authorization problems. These result in being logged out and sent to the login screen.
en_GB: ``UNAUTHORISED``: Errors resulting from authentication or authorisation problems. These result in being logged out and sent to the login screen.

en: ``horizon.defaults`` for horizon
en_GB: ``horizon.defaults`` for Horizon

en: ``horizon`` is the location of horizon
en_GB: ``horizon`` is the location of Horizon

en: ``tox -e npm`` from the horizon root directory.
en_GB: ``tox -e npm`` from the Horizon root directory.

en: ``tox -e npm`` from the horizon root directory. This runs Karma, so it will run all the tests against PhantomJS and generate coverage reports.
en_GB: ``tox -e npm`` from the Horizon root directory. This runs Karma, so it will run all the tests against PhantomJS and generate coverage reports.

en: `openstack_auth/policy.py`: `_load_default_rules` function loads the YAML files with default rules and call `register_defautls` method of the policy enforcer per service.
en_GB: `openstack_auth/policy.py`: `_load_default_rules` function loads the YAML files with default rules and call `register_defaults` method of the policy enforcer per service.

en: base token auth url
en_GB: base token auth URL
