Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/snap: don't translate service statuses in 'snap services' output #10750

Closed

Conversation

stolowski
Copy link
Contributor

It was rightfully pointed out in https://bugs.launchpad.net/snappy/+bug/1941926 that translating service statuses makes it hard to handle 'snap services' in scripts, so this PR drops i18n around service status. I think 'snap services' should be usable for scripts just like 'systemctl' is.

@stolowski stolowski added Simple 😃 A small PR which can be reviewed quickly Bug labels Sep 7, 2021
@zyga
Copy link
Collaborator

zyga commented Sep 7, 2021

I guess that's just an opinion but shouldn't scripts that rely on parsing set LANG?

@codecov-commenter
Copy link

Codecov Report

Merging #10750 (c009772) into master (d1008b6) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master   #10750   +/-   ##
=======================================
  Coverage   78.37%   78.38%           
=======================================
  Files         887      887           
  Lines       99751    99751           
=======================================
+ Hits        78180    78187    +7     
+ Misses      16669    16663    -6     
+ Partials     4902     4901    -1     
Flag Coverage Δ
unittests 78.38% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
cmd/snap/cmd_services.go 80.16% <100.00%> (ø)
overlord/ifacestate/helpers.go 77.52% <0.00%> (+0.49%) ⬆️
daemon/api_connections.go 93.58% <0.00%> (+1.60%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1008b6...c009772. Read the comment docs.

@@ -138,15 +138,15 @@ func (s *svcStatus) Execute(args []string) error {
fmt.Fprintln(w, i18n.G("Service\tStartup\tCurrent\tNotes"))

for _, svc := range services {
startup := i18n.G("disabled")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm not sure, I would say that scripts should set LC_ALL=C or one of the other variables.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made this as a suggestion in the bug instead, @stolowski I'm closing this instead.

@ted-gould
Copy link

I would challenge you to find a tutorial on the Internet on script writing that says "change the language first" -- it doesn't happen. Part of that is because computers are American centric and that isn't good. But at a practical level what it means is that everyone's test suite is only going to run in English, and there'll be errors for everyone else on the planet. The developer won't understand it and just report the bug as WORKSFORME.

Frankly, that's what my snaps do. 🤷‍♂️

@ted-gould
Copy link

Also, though the code is shared I'll say that I feel much more strongly about this in snapctl than in the snap utility. The snapctl utility is only used in scripts while snap is in theory used by humans.

@mardy
Copy link
Contributor

mardy commented Sep 8, 2021

Also, though the code is shared I'll say that I feel much more strongly about this in snapctl than in the snap utility. The snapctl utility is only used in scripts while snap is in theory used by humans.

That's a very good point. But it seems to me that the code is not shared: the part for snapctl is here, and I fully agree that that part should not be using i18n.G().

@mardy
Copy link
Contributor

mardy commented Sep 8, 2021

BTW, we have some code in cmd/snap/main.go that determines if the terminal is a TTY; it would be nice if we could somehow hook that into i18n.G() to make it return the untranslated string if the terminal is not a TTY. :-)

@stolowski
Copy link
Contributor Author

BTW, we have some code in cmd/snap/main.go that determines if the terminal is a TTY; it would be nice if we could somehow hook that into i18n.G() to make it return the untranslated string if the terminal is not a TTY. :-)

Yes we use terminal.IsTerminal() check in a couple of places when it comes to formatting or escape sequences, but I fear about discoverability if it was used in this context, it could be very confusing as one usually looks at tty output first when working on a script.

@pedronis pedronis self-assigned this Sep 27, 2021
@pedronis
Copy link
Collaborator

pedronis commented Dec 8, 2021

I'm closing this. OTOH we should take a decision whether to remove all i18n from snapctl.

@pedronis pedronis closed this Dec 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Simple 😃 A small PR which can be reviewed quickly
Projects
None yet
7 participants