LOG messages localized, shouldn't be

Fix proposed to branch: master
Review: https://review.openstack.org/144345

Change abandoned by David Lyle (<email address hidden>) on branch: master
Review: https://review.openstack.org/144345
Reason: best to just start over on this

Fix proposed to branch: master
Review: https://review.openstack.org/173974

When I debugged horizon as an operator today, I encountered this issue.
Log messages with various languages which an operator cannot understand is really tough.
It should be fixed as soon as possible.

One good example is:

Recoverable error: \xe5\x88\xa9\xe7\x94\xa8\xe5\x8f\xaf\xe8\x83\xbd\xe3\x81\xaa\xe3\x82\xb3\xe3\x83\xb3\xe3\x82\xbd\xe3\x83\xbc\xe3\x83\xab\xe3\x81\x8c\xe3\x81\x82\xe3\x82\x8a\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82'

It is Japanese text, but even Japanese can read it without decoding.

It is hard for operators to understand :(

I left a comment on the patch but repeating it here: I don't think workarounds where we use the same string for Logs and user messages are an acceptable solution, because those strings should *always* be different.

It's more manual work, but a separate string should just be declared for the logs, that isn't translated and contains verbose feedback (like stack traces); the User message should be a simple translated string, indicating a failure and a short summary of the reason, if it is available.

Even if we have separate log messages for exceptions, we'll still need a fix like this if we want to log what user messages we're sending to the front end. Most logs in horizon do just this already, and log the actual exception and trace first and then follow it up by saying what we're sending to the front end, and thats what causes the translation objects to end up in the logs.

What's the point in logging an untranslated version of a translated user string? It's not like you could even search for it while tracking down the error, because it won't be the same message the user has seen unless they're using it in English.

You'd either actually want to *keep* the translated string, so you can search the logs for whatever message your user saw, or stop logging them entirely, as they have no value.

Change abandoned by Sam Betts (<email address hidden>) on branch: master
Review: https://review.openstack.org/173974
Reason: It was decided that a different approach should be taken.

Quoted from the last comment in https://review.openstack.org/173974

> discussed this at the summit, I think we should have a different approach, logging a more detailed error message to the log, putting a lighter and translated message to the end user.

A straight-forward approach to use different messages for log and user-visible message looks a way we go.

Clear assignee due to inactivity

Fix proposed to branch: master
Review: https://review.openstack.org/455635

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

commit ced987815d6a091fbcedbd4c319395038cb3f976
Author: Akihiro Motoki <email address hidden>
Date: Tue Apr 11 10:24:01 2017 +0000

    Ensure log messages are not translated

    Previously translated messages are included in log messages
    and it was determined what language is chosen by users.
    It makes difficult for operators to understand log messgaes.

    This commit tries to use English messages for all log messages.
    The following policies are applied based on the past discussions
    in the bug 1406333 and related reviews.

    - English messages are used for log messages.
    - log messages include exception messages if possible
      to help operators identify what happens.
    - Use ID rather than name for log messages
      as ID is much more unique compared to name.
    - LOG.debug() in success code path are deleted.
      We don't log success messages in most places and API calls to
      back-end services can be logged from python bindings.

    Change-Id: Ie554463908327435d886d0d0f1671fd327c0cd00
    Closes-Bug: #1406333

This issue was fixed in the openstack/horizon 12.0.0.0b2 development milestone.

neutron-fwaas-dashboard and neutron-vpnaas-dashboard are affected. They were split out from horizon after the fix for this bug was merged, but unfortunately the split out codes were prepared before the fix was merged. Needs to take care of it.

woops... neutron-fwaas-dashboard is not affected.

Fix proposed to branch: master
Review: https://review.openstack.org/492044

Reviewed: https://review.openstack.org/492044
Committed: https://git.openstack.org/cgit/openstack/neutron-vpnaas-dashboard/commit/?id=66c1e460865d64a6ce8ce454a81048e2bdafa9eb
Submitter: Jenkins
Branch: master

commit 66c1e460865d64a6ce8ce454a81048e2bdafa9eb
Author: Akihiro Motoki <email address hidden>
Date: Wed Aug 9 08:43:49 2017 +0000

    Ensure log messages are not translated

    This is VPNaaS dashboard version of the horizon patch
    https://review.openstack.org/#/c/455635/.
    The horizon patch was merged before VPNaaS dashboard split out,
    but unfortunately I failed to import the change.

    The following describes the rational of this change
    (quoted from the horizon change).
    ----
    Previously translated messages are included in log messages
    and it was determined what language is chosen by users.
    It makes difficult for operators to understand log messgaes.

    This commit tries to use English messages for all log messages.
    The following policies are applied based on the past discussions
    in the bug 1406333 and related reviews.

    - English messages are used for log messages.
    - log messages include exception messages if possible
      to help operators identify what happens.
    - Use ID rather than name for log messages
      as ID is much more unique compared to name.
    - LOG.debug() in success code path are deleted.
      We don't log success messages in most places and API calls to
      back-end services can be logged from python bindings.

    Change-Id: I1a37b7ccbfa29cd83456931f7864ad9ce31aa570
    Closes-Bug: #1406333