Internationalization improvements

[craicoverflow]

Up until now we have been add i18n for nearly every text string through the entire repository. This has a number of drawbacks and I think we should reconsider where we use i18n:

Slower development

It is really slow to add or update a text string because you have to go over and back between 2-3 different files.

Readability

The code is not as readable any more because you need to reference a message ID, and go check that the actual text say in the locales file.

Prone to runtime errors

The most common kind of error in the CLI we have seen was from runtime errors caused by wrong locale message IDs being referenced in code. Often it can go undetected unless you execute that flow, and some are less commonly hit than others.

Harder to reuse code

We have a lot of public facing APIs, including the command packages, config and Connection. All of these could be useful to other libraries wishing to use it. We have seen that having localized static files used in these packages renders them unusable to external libraries.

I did a large refactor in #638 which changed 128 files to use go embed which gives native support for static files. In this PR I also abstracted from go-i18n and made the API a little better than the library provides. This will improve the experience somewhat but the above drawbacks will persist.

Proposal

What I propose is that we have a clear definition of what should be localized and what should not be (or be optional). I think all that we really need localized are the elements which will be transformed to documentation - i.e commands, usage, help text, flags etc.
Code used thereafter such as error messages, interactive text etc. can just be plain text.

[wtrocki]

Code used thereafter such as error messages, interactive text etc. can just be plain text.

+100 on having this plus debug statements etc.
All of that will drastically improve reusability of SDK

[pmuir]

There is no need to internationalize debug info - this should exist for the user to turn on when they need to report a problem to us (and we work in english!). However, anything that is user facing it would be good to internationalize - this should include usage text, help text, error messages, interactive prompts. I'm not sure that we should be internationalizing command names or parameter names.

It does make development and debugging harder not having the text in the code, however I wonder if we can provide better tooling for this somehow?