Open Stack

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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>