csantanapr opened a new issue #139: CLI error messages are replicated three 
times
URL: https://github.com/apache/incubator-openwhisk-cli/issues/139
 
 
   @rabbah commented on [Wed Apr 05 
2017](https://github.com/apache/incubator-openwhisk/issues/2113)
   
   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. 
   
   ---
   
   @dubeejw commented on [Mon Apr 10 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-293037821)
   
   Related to https://github.com/openwhisk/openwhisk/issues/2063.
   
   ---
   
   @rabbah commented on [Thu Apr 13 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-293915293)
   
   @dubeejw should this be done more expeditiously so as not to perpetuate this 
further especially with more CLI work picking up?
   
   @RSulzmann FYI.
   
   ---
   
   @rabbah commented on [Thu Apr 13 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-293915513)
   
   Also @dubeejw should we combine 2113 and 2063?
   
   ---
   
   @lzbj commented on [Tue Jul 11 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-314388282)
   
   @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 commented on [Tue Jul 11 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-314476062)
   
   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 commented on [Tue Jul 11 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-314476401)
   
   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 commented on [Wed Jul 12 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-314706292)
   
   thanks for your clarification, I submitted one pr 
https://github.com/apache/incubator-openwhisk/pull/2475, please help review if 
you available, thanks.
   
   ---
   
   @lzbj commented on [Mon Jul 17 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-315947757)
   
   https://github.com/apache/incubator-openwhisk/pull/2502
   
   ---
   
   @drcariel commented on [Wed Jul 19 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-316506234)
   
   @mdeuser This is the issue we discussed, wondering if there are any tips or 
preferred styles for updating the String references?
   
   ---
   
   @mdeuser commented on [Wed Jul 19 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-316541093)
   
   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 commented on [Thu Jul 20 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-316798471)
   
   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 commented on [Sun Jul 23 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-317251883)
   
   > It still seems more efficient, in respect to ease of maintenance, to 
shorten the reference names
   
   +1 
   
   ---
   
   @drcariel commented on [Tue Jul 25 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-317538963)
   
   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 commented on [Tue Jul 25 
2017](https://github.com/apache/incubator-openwhisk/issues/2113#issuecomment-317722562)
   
   @drcariel -  thanks for digging into the current best practices. I agree we 
can move away from having the resource key match the actual text.
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to