On Sun, May 22, 2016 at 01:32:20PM +1000, Ben Finney wrote: > On 21-May-2016, David Kalnischkies wrote: > > As an example, your changes in the context of gpgv are incorrect as > > the official term in rfc2440 for the "key-value pairs" is "Armor > > Header" not field as you suggest and even if that is grossly > > inconsistent I don't think its a good idea to change this. > > The documentation refers to the “armor header” as the collection of > name-value pairs that head the armor. I have now followed this > terminology. No. RFC2440 refers to a "key-value pair" as "Armor Header" (in that casing). A collection of those is called "Armor Headers" – compare §6.2 (especially the two paragraphs above the "Armor Header Key" list). > > In the context of http(-like) the more correct term might be "header > > fields" which you use sometimes (then you replaced a 'line'), but > > not always. In comments just "fields" might be correct much like the > > RFC uses it in long paragraphs where its clear what is meant, but in > > error messages we should perhaps be using the full term. > > I have tried to make minimal changes to the text of messages. For many > context there is no other kind of field, so “field” suffices in most > places. In messages displayed to users any change is a "big" change (see translations below), so being verbose isn't a problem – especially as we can't make any assumptions about the context such error messages will be print in and the user reading them. > > (btw: the registry for "Message Header Field Names" is called > > "Message Headers", so using "headers" isn't as inconsistent as you > > make it sound) > > If that name is used, it's another inconsistency :-) https://www.iana.org/assignments/message-headers/message-headers.xhtml See RFC7231: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" §8.3 among others, so… good luck changing that I presume. > > Changing the tests/integration/status-* files is interesting in so > > far as you are modifying the descriptions of actual packages (which > > might or might not be changed in the meantime). > > Do those packages actually exist? I didn't realise. Usually they do… The status-* and Packages-* files tend to be (reduced) real-world examples. There are exceptions in which they are completely constructed, but those are quite obvious if you see them… The package in question is 'insserv' btw, which still has this description and I would assume they have field knowledge, so I would pass such a change up to them first. (And yes, in theory changes to those files can modify the tests – in practice in these two instances they wont as these tests do not deal with Descriptions) > > In the documentation you do typo/style fixes (FDs, URIs, HTTP, …) > > which should be fixed in the translations (doc/po) as well to avoid > > needless fuzzies. > > I am not sure how to do this (I am not familiar with proper use of > gettext). I only changed terms in the area where I was already > changing “header” and “field” terminology. > > Which files should I modify for translation? Some are auto-generated, > I think. Yes, *.pot files are traditionally auto-generated from the sources. It is needed if you want to start a new translation. It is also used to update existing translations (*.po) automatically by marking all strings which were changed as "fuzzy" so a translator has to review them before they are used again which is unneeded busywork if all what is done in the message is a fixed typo. I tend to do it manually, but there are also tools to help you: man 1p msguntypot. You are lucky, most of your changes are to files which aren't translated – looks for me like its just one and in that commit you modified the pot file, too. Given that this is just changing a Translator comment, its a prime candidate for msguntypot. > doc/Doxyfile.in The file is semi-autogenerated as in: While it contains our configuration for doxygen, it is updated by "doxygen -u" (manually) which is reverting your changes to the comments, so you will have to talk to doxygen upstream as this isn't our doing (and effects ever doxygen user). > rfc822-style If I have seen it right, we talk about our own method-interface here, which for self-containment is probably better described as deb822 style as we have that around as a manpage while rfc822 deals with all sorts of things not applying to us. > rfc2616 Is superseded by now (7230-7237), so it shouldn't be referred to anymore the HTTP protocol anymore. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature