Openwhisk: CLI error messages are replicated three times

[rabbah]

The cli refers to error messages not by a short tag but a string that is the error message. The translation file then repeats the same message again. Why is it done this way instead of a short descriptive name for the error? So that only the transalation (actual error msg) needs to be fixed, once.

[dubee]

Related to https://github.com/openwhisk/openwhisk/issues/2063.

[rabbah]

@dubeejw should this be done more expeditiously so as not to perpetuate this further especially with more CLI work picking up?

@RSulzmann FYI.

[rabbah]

Also @dubeejw should we combine 2113 and 2063?

[lzbj]

@rabbah , do you mean this kind of replication
https://github.com/apache/incubator-openwhisk/blob/master/tools/cli/go-whisk-cli/commands/action.go#L596

we can perhaps use pointer instead of string copying to make it more faster.

[rabbah]

I mean the replication in the error messages themselves like this:

errMsg := wski18n.T(
    "Unable to create action '{{.name}}': {{.err}}",

Search for the string:

    "Unable to create action '{{.name}}': {{.err}}"

You will see it's repeated so making a change to any error message requires fixing all the refeerences. These should be via indirection, a pointer as you suggest.

[rabbah]

Here are the three copies as one example https://github.com/apache/incubator-openwhisk/search?utf8=%E2%9C%93&q=++++%22Unable+to+create+action+%27%7B%7B.name%7D%7D%27%3A+%7B%7B.err%7D%7D%22&type=

[lzbj]

thanks for your clarification, I submitted one pr https://github.com/apache/incubator-openwhisk/pull/2475, please help review if you available, thanks.

[lzbj]

https://github.com/apache/incubator-openwhisk/pull/2502

[drcariel]

@mdeuser This is the issue we discussed, wondering if there are any tips or preferred styles for updating the String references?

[mdeuser]

I looked at another CLI project written in Go, and all of the resource strings followed the convention currently used by this CLI. @drcariel - Can you scrounge around a bit more for other globalized Go projects to get a sense of the resource key best practice.

[drcariel]

I have seen the same after doing a bit of investigation. Do you think that is the standard?

It still seems more efficient, in respect to ease of maintenance, to shorten the reference names, but I leave the final decision to you @mdeuser

[rabbah]

It still seems more efficient, in respect to ease of maintenance, to shorten the reference names

+1

[drcariel]

Just discussed with my old team.

Their initial decision to externalize the reference names as the actual strings was due to the misunderstanding that that was a requirement for translation to work properly. A new team has since taken over that project and made the decision to use shortened names.

I was given this as a reference for bluemix CLI guidelines:
https://github.com/IBM-Bluemix/bluemix-cli-sdk/blob/master/docs/plugin_developer_guide.md#6-globalization

and while their example shows the id and translation as the same, it's important to note that this is their single example, not a hard requirement. If we take a look at the actual 3rd party translation library documentation (https://github.com/nicksnyder/go-i18n#workflow) you see another style of shortened reference names.

Knowing what freedoms we have now, I think we absolutely should shorten these references with our own style or an existing one, especially as an open-sourced project.

[mdeuser]

@drcariel - thanks for digging into the current best practices. I agree we can move away from having the resource key match the actual text.

[csantanapr]

Issue moved to apache/incubator-openwhisk-cli #139 via ZenHub