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

Inconsistent CLI options documentation #68

Open
mattias-p opened this issue Feb 6, 2018 · 16 comments
Open

Inconsistent CLI options documentation #68

mattias-p opened this issue Feb 6, 2018 · 16 comments
Assignees
Labels
A-Documentation Area: Documentation only. P-High Priority: Issue to be solved before other T-Bug Type: Bug in software or error in test case description
Milestone

Comments

@mattias-p
Copy link
Member

mattias-p commented Feb 6, 2018

The command line options are documented in two different ways. The two different documentations can be show with the commands zonemaster-cli --help and man zonemaster-cli respectively. Both commands should output the same documentation.

@mattias-p
Copy link
Member Author

MooseX::Getopt::Usage could be part of a solution to this.

@sandoche2k sandoche2k added the P-High Priority: Issue to be solved before other label Mar 13, 2019
@sandoche2k sandoche2k added this to the v2019.2 milestone Mar 13, 2019
@matsduf matsduf assigned vlevigneron and unassigned mattias-p May 28, 2019
@matsduf
Copy link
Contributor

matsduf commented Aug 5, 2019

The top part of man zonemaster-cli (options) is more or less identical to zonemaster-cli --help, but not completely:

  • They are presented in different ways.
  • man is in English only, --help is partly translated.
  • Some options are mentioned in help only, such as --config and --sourceaddr.

Make those to be identical by just defining it once. In the implementation the man page comes from the script zonemaster-cli and the help comes from CLI.pm.

The is an option --usage which gives the same as --help. Confusing.

@matsduf matsduf modified the milestones: v2019.2, v2019.3 Oct 31, 2019
@matsduf matsduf modified the milestones: v2019.3, v2020.1 Nov 20, 2019
@matsduf matsduf added A-Documentation Area: Documentation only. T-Bug Type: Bug in software or error in test case description labels Nov 21, 2019
@matsduf matsduf assigned matsduf and unassigned vlevigneron May 28, 2020
@matsduf matsduf modified the milestones: v2020.1, v2020.2 Oct 15, 2020
@matsduf matsduf modified the milestones: v2020.2, v2021.1 Feb 9, 2021
@matsduf matsduf modified the milestones: v2021.1, v2021.2 May 27, 2021
@matsduf matsduf assigned vlevigneron and unassigned matsduf Jul 29, 2021
@matsduf
Copy link
Contributor

matsduf commented Jul 29, 2021

@vlevigneron, I have failed to find a good solution on this. Can you take a look at it?

@vlevigneron
Copy link
Contributor

vlevigneron commented Jul 29, 2021 via email

@matsduf
Copy link
Contributor

matsduf commented Jul 29, 2021

This issue is related to #160.

@vlevigneron
Copy link
Contributor

I see that @matsduf and I have no idea how to fix #160. What we see is what is expected from MooseX::Getopt. I found no way to change that behaviour in the doocumentation.

@matsduf
Copy link
Contributor

matsduf commented Jul 30, 2021

Could we migrate from MooseX::Getopt? It works for very few options but not for the Zonemaster use case.

@vlevigneron
Copy link
Contributor

Everything is possible but it would be a complete rewrite of zonemaster-cli/lib/Zonemaster/CLI.pm.

@matsduf
Copy link
Contributor

matsduf commented Jul 30, 2021

I have struggled to make MooseX::Getopt not print out, but I have failed. Is it possible to create a "catch all" option and then let that print an error message and use "perldoc zonemaster-cli" for the documentation?

@vlevigneron
Copy link
Contributor

I guess I found something. I'll create a PR today, you'll see if it is an acceptable workaround.

@mattias-p
Copy link
Member Author

Would it be acceptable to drop the translation of the help output? I would say yes definitely. Do you guys agree?

@matsduf
Copy link
Contributor

matsduf commented Mar 22, 2022

Would it be acceptable to drop the translation of the help output?

Is that the equivalent to "man zonemaster-cli" or do you mean all output?

$ zonemaster-cli --locale sv_SE.UTF-8
Måste ange namnet på en domän att testa.

$ zonemaster-cli
Must give the name of a domain to test.

If you only mean the equivalent of "man zonemaster-cli" I think it is OK.

@mattias-p
Copy link
Member Author

I mean zonemaster-cli --help.

@ghost
Copy link

ghost commented Mar 22, 2022

Would it be acceptable to drop the translation of the help output?

This sounds reasonable to me. However, and I don't know how feasible it is, since it seems we have translations for zonemaster-cli --help, can't we use the translations for the man pages? Or are they using different part of the code, so translating the man page is a job on its own?

@mattias-p
Copy link
Member Author

mattias-p commented Mar 22, 2022

My idea was to switch approaches and do what I usually do for documentation of CLI tools. I.e. to specify the options using Getopt::Long, document them in POD and perform the usage output with Pod::Usage. All of these are included in the Perl Core, so we could probably drop CLI's dependency on Moose that way. And the end result would be rather nice for both users and maintainers. Except for users who really need the usage translations, of course. So I guess the question is how important this feature is.

If we must have the usage translations we'll have to come up with a new approach. Because Gettext doesn't work for POD. At least not as far as I know.

@matsduf
Copy link
Contributor

matsduf commented Mar 23, 2022

I think it is nice to have all output translatable, but it would be acceptable to have the output from "--help" in English only. Other output we should keep translatable.

It is a question of resources and priorities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Documentation Area: Documentation only. P-High Priority: Issue to be solved before other T-Bug Type: Bug in software or error in test case description
Projects
None yet
Development

No branches or pull requests

4 participants