On 04/07/2014 11:57 PM, Peng Wu wrote:
Thanks for the comments.
Maybe we could just search the English log. :-)
Right, but the problem is that the English log is not guaranteed to
remain the same. An (extremely contrived) example:
Say we have a log message like "Failed to not find entity: %s"
That's really confusing because of the double negative. So we change it
to "Found an unexpected entity: %s". It's highly unlikely that a search
for the changed message is going to also turn up a blog post or whatever
about the first message.
Granted the example is contrived, but I've seen just that sort of log
message rewording done in real changes too.
Maybe the dual logging is enough for everyone, but I don't think it
addresses all of the reasons for wanting message ids so I don't think we
can just say we're not going to do message ids because of it. It's
perfectly valid to say we're not going to do message ids because no one
wants them enough to actually implement them though. :-)
But I just find it is hard to meet all requirements of log message id,
Just some thought that we can avoid the message id generation by using
the English log.
For debug purpose, we can just read the English log.
Regards,
Peng Wu
On Mon, 2014-04-07 at 11:19 -0500, Ben Nemec wrote:
On 04/03/2014 10:19 PM, Peng Wu wrote:
Hi,
Recently I read the "Separate translation domain for log messages"
blueprint[1], and I found that we can store both English Message Log and
Translated Message Log with some configurations.
I am an i18n Software Engineer, and we are thinking about "Add message
IDs for log messages" blueprint[2]. My thought is that if we can store
both English Message Log and Translated Message Log, we can skip the
need of Log Message ID Generation.
I also commented the "Add message IDs for log messages" blueprint[2].
If the servers always store English Log Messages, maybe we don't need
the "Add message IDs for log messages" blueprint[2] any more.
Feel free to comment this proposal.
Thanks,
Peng Wu
Refer URL:
[1]
https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain
[2] https://blueprints.launchpad.net/oslo/+spec/log-messages-id
As I recall, there were more reasons for log message ids than just i18n
issues. There's also the fact that an error message might change
significantly from one release to another, but if it's still addressing
the same issue then the message id could be left alone so searching for
it would still return relevant results, regardless of the release.
That said, I don't know if anyone is actually working on the message id
blueprint so I'm not sure how much it matters at this point. :-)
-Ben
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
