-
Notifications
You must be signed in to change notification settings - Fork 33
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
Naming of domain message args #854
Merged
Merged
Changes from 6 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
c1ced7f
Fix message args for NSEC_SIG_VERIFY_ERROR
mattias-p 864b556
Unused messages
mattias-p a904074
Refactor
mattias-p d908de3
Rename msgid arg: domain
mattias-p 0b62b44
Update msgid arg names in PO files
mattias-p 92196a8
Tidy PO files
mattias-p cde4261
Clean up fuzzy markers
mattias-p 51d170d
Make domain refer to nsname
mattias-p File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A domain name on what? There is already "nsname" with the same data type. The description should be more specific so that it excludes name server names, or else there should only be one.
One approach is to let instances of domain name be represented by the same argument, e.g. "domain". In the case of non-negative integer you have taken the path to have different arguments for different use of non-negative number. If the same path is followed for domain name I find the split name server name, on one side, and all other use of domain name, on the other, not to be optimal for Zonemaster.
There are some domain names that are special for Zonemaster in the sense that they point out central concepts and are frequent.
Other use that we have include
If there are more than one argument for data type domain name, then at least the first three (name server name, zone name of parent and zone name of child) should be their own arguments. The last three could be grouped into one argument, but could as well be their own arguments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a relevant and difficult topic you bring up. But I'll try to spell out how I'm think about it. Maybe we ought to take it offline, but I want to gather my thoughts in text anyway so I'll just post it here. Bare in mind that since I started working with this my perspective has been evolving.
First of all I doubt we'll be able to find a perfect design for the argument naming. I have a feeling that no matter how we turn in this question, we'll have our butts behind us.
I see a few main reasons to have give variables different names.
In the first case the format of an argument value might affect the best way to punctuate a message, so it's seems helpful to provide translators with a hint to that end.
I apply the same general idea to the second case. If the unit of an argument value might affect the language around it, it's seems helpful to provide a hint for that.
The third case is different in my mind. It seems impossible to come up with a partitioning of different kinds of variables that's both reasonable and granular enough to ensure that no message will need to use two variables of the same kind. We need some kind of general disambiguation solution. My first choice for solving this problem is using common prefixes that indicates the kind of variable together with locally unique disambiguation suffixes.
A way to mitigate the ambiguity problem and reduce (though not eliminate) the need for disambiguation suffixes is to single out a few very common sub-kinds and promote them to a proper kind of their own. The obvious example here is nsname which I estimate to be about a third of all domain name arguments.
Returning to your question "A domain name on what?". In my mind the msgid ought to be good enough to answer what kind of domain name. From my current understanding of the issue, I don't see any reason to disambiguate different kinds of domain names any further than "domain" and "nsname". If it can be shown that having distinct kinds for "nsname" doesn't help much with disambiguation, I think we should at least consider integrating it into the generic domain kind. The same goes for the special kinds of integers.