I18n: strings in some table columns (e.g., Status, Task, Powerstate) are not translated

[Ying Chun Guo]

There are many tables in Horizon. I noticed some columns are untranslated. For example, in the table of instances, strings in the column of "Status", "Task", and "Power State" are not translated. In the table of volumes, strings in the column of "Status" are not translated. In the table of images, strings in the column of "Type", "Status", "Public", and "Protected" are not translated.

Some of these strings are getting from database as code, for example "Type" and "Status". Some of these strings are "Yes" and "No". I think they should also be enabled i18n too.

[Julie Pichon (jpichon)]

It's difficult since we're getting this data back from Nova/Glance etc and as far as I know, there is currently no way (?) to request the strings to be returned in a specific language.

We could duplicate the list (like we do e.g. when messages returned are unclear [0] - I suddenly notice that these strings are not marked as translatable!) and do a 1-on-1 mapping to have translatable strings but it doesn't seem very DRY, nor does it scale well as new messages will get added to the other services.

Currently the yes/no strings in Public/Protected for Images are correctly showing in the target language for me (using Japanese to test).

[0] https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/tables.py#L506

[Peng Wu (alexepico)]

Recently I just found the horizon/templatetags/sizeformat.py file.

How about we introduce an stateformat.py file to translate the states of VM in horizon?

Or add some dict mapping for "Status", "Task", and "Power State" in openstack_dashboard/dashboards/project/instances/tables.py?

[Ying Chun Guo (daisy-ycguo)]

I know Oslo team is working on a feature "late translation" which allows REST API response messages to be translated as client side requested. But it is only the message translation, not the "code" (for example, the status code) translation.

I think the way Peng Wu proposed is to translate the "code" to "description" in local language in the Web UI side. It is a possible solution.

Regards
Daisy

[Peng Wu (alexepico)]

Take the "Status" for example:

    STATUS_CHOICES = (
        ("active", True),
        ("shutoff", True),
        ("suspended", True),
        ("paused", True),
        ("error", False),
    )

I propose to change the above code to:

    STATUS_CHOICES = (
        ("active", True, _("active")),
        ("shutoff", True, _("shutoff")),
        ("suspended", True, _("suspended")),
        ("paused", True, _("paused")),
        ("error", False, _("error")),
    )

Then the horizon Web UI can display the translated status message.

[Julie Pichon (jpichon)]

I'm a bit reluctant to try and duplicate all the strings from the other projects, it doesn't seem scalable as more and more strings get added elsewhere, and it will force translators to translate the same thing twice (hopefully in the same way) in 2 different projects.

Then again perhaps it makes sense for a few key panels, like the Instances one, if we're not getting any closer to the right solution being ready.

I'm not aware if there's any work in progress (or existing work?) to specify a language for the response, in any of the clients. Daisy, do you know?

[Luis A. Garcia (luisg-8)]

I just want to comment that the delayed translation feature from Oslo will allow REST API responses to be translated but only when they are translatable, for example on error messages. However, I have not seen any API that translates the values for object attributes such as "state".

I think the solution to this would be to add REST API contributions that translate the actual state (and other necessary attributes) and expose the translated label, which would use the new Oslo delayed translation. Then horizon can show that new attribute say "stateLabel" instead of "state".

[Peng Wu (alexepico)]

personally I prefer not to translate the object attributes.

In the horizon web UI, we need code to check the "state" object attribute.
In order to display the state, and provides available operations, need code like:
instance.status == "SUSPENDED"

If the servers translates the object attribute, the code may becomes:
instance.status == _("SUSPENDED")
if the above "instance.status" stores the translated status from the server.

If the translations of the client and server mis-matches, some un-expected bugs may appears.
maybe good to not translate object attributes...

[Peng Wu (alexepico)]

After read the comments of "horizon/tables/base.py", I think "display_choices" is a better choice for i18n support than "status_choices".

In "openstack_dashboard/dashboards/project/instances/tables.py", I moved "STATUS_CHOICES" to "STATUS_DISPLAY_CHOICES".

Sorry, I am new to openstack, the patch only addresses the "Status" column, I will address other columns in later patches.
Please review it, thanks.

[Julie Pichon (jpichon)]

Peng Wu, if you wish to propose a patch you should do so via Gerrit, the system used by OpenStack. You can find more information at http://wiki.openstack.org/GerritWorkflow . Feel free to ask for help on IRC at #openstack-horizon if you encounter any issue.

Note that you should not remove the STATUS_CHOICES list. It's used to determine whether we need to automatically update the row via ajax (when we expect a status change).

[Luis A. Garcia (luisg-8)]

Just wanted to clarify that I was not proposing translating the actual "state" value, because that has to be constant in order for consumers to be able to reliably parse it and use the value. I was proposing adding a second field called "stateLabel" that returns the translated value and that gets sent back in addition to the actual "state". The value of "stateLabel" would get transalted to whatever the value of HTTP Accept-Language is. We can re-use logic currently in wsgi to figure out the desired langauge for the user and just translate the corresponding attribute in the response. I think this solution is actually more reusable than a horizon specific solution, because it can be used by other API consumers like the CLI.

[Ying Chun Guo (daisy-ycguo)]

I think the key argument between Peng's solution and Luis's suggestion is whether to do the translation in Horizon (client) side or not ( in server side).
I think, we need to evaluate the workload and pros/cons of each solution and then decide.

[Peng Wu (alexepico)]

I uploaded a draft patch to gerrit review, see:
https://review.openstack.org/#/c/68868/
Feel free to comment it.

And I found that the status in nova of "./nova/api/openstack/common.py" seems not translated yet.
To let gettext find these status strings, all status strings need to be putted in _("...") like _("RESIZE"), which may also need to duplicate the strings in nova code.
Feel free to correct me, if I am wrong about it.

[Julie Pichon (jpichon)]

Thanks Luis, the stateLabel suggestion is interesting. Is there a bug/blueprint open for this in the clients or Oslo?

[Luis A. Garcia (luisg-8)]

Hi Julie, I don't think there is a bp for this. I was just proposing it as a solution to this bug. The implementation would be in the REST API for each project. I can type it up and propose it if needed. Thank you,

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/68868
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=63911d3903c94338b425779e67bd85db23eb9829
Submitter: Jenkins
Branch: master

commit 63911d3903c94338b425779e67bd85db23eb9829
Author: Peng Wu <email address hidden>
Date: Mon Jan 20 17:00:26 2014 +0800

    Fixes some column translations

    add more entries to "display_choices" of "Status", "Power" and
    "Task" column, in order to get the states translated.

    Closes-Bug: #1224329
    Change-Id: I22ee666678c8bce24c2d6c696438b481006bd609