Re: the prohibited "you"

Bjoern,

Thanks for your feedback.  Some comments and questions embedded...

At 05:18 AM 4/25/2004 +0200, Bjoern Hoehrmann wrote:

>[...] I would however suggest to rephrase it, for example
>
>   Comments on this document should be sent to the publicly archived
>   www-qa@w3.org mailing list.
>
>or probably even better
>
>   Please send comments on this document to the publicly archived
>   www-qa@w3.org mailing list.
>
>You don't need to mention twice that the list is public/archived or what
>the maintaining group of the list is, and it is also a bit odd if the WG
>tells reviewers to send comments to the IG. And, of course, feedback
>should be explicitly invited.

Sounds fine to me.  I'll fly it by our staff contact(s), who provided the 
boiler plate that we currently use.


> >Second question, for language experts.  What is the problem with
> >translating "you" to other languages?  Okay, in French one would have to
> >choose between vous and tu, in German between sie and du, etc.  I would
> >chose the more formal:  vous, sie, etc.  So what problem would that present?
>
>Directly addressing the reader might be confusing, who is "you"? You
>might have a broad audience, "you" might be a reviwer of the very
>document, it might be a reviewer of another document using QA materials
>as additional material for reference in comments, it might be an editor,
>etc.

With the revised QA Framework ("Lite"), we had hoped to make the target 
audience of each part very clear, e.g., "spec editors" or "Chairs & Staff 
Contacts."  Do you think that would mitigate this first concern 
somewhat?  (Btw, the "you" style was a popular idea in the WG, as a piece 
of making the style of QA-Lite less fierce and authoritarian.  I'm not 
particularly attached to it and in fact have already revised it out of my 
parts.)

>[...]
>   "Specify the character encoding of the document."
>
>The questions remain. It won't get much better if you use terms like
>"take care", "ensure", etc.

I would agree that this is dubious style for the given example.  Especially 
if this were the only statement of the requirement, and it is a goal that 
conformance to specifification be rigorously and objectively 
verifiable.  The target of the requirement is not a person, as the 
imperative voice would suggest.  Rather, it is a particular and easily 
stated requirement about the document.

>What is important here? Software needs to
>know the encoding of the document in order to properly decode it. If
>it is not specified, it might refuse to process the document or attempt
>to guess the encoding which might fail or yield in broken data. If you
>manage that the reader actually *understands* this and is *convinced*
>that this is important, all he additionally needs to know is how he can
>do it, he will then ensure that the character encoding is properly
>specified for the documents he is responsible for, one way or another.
>Telling readers to do it is basically useless, readers want to draw
>their own conclusions from your input, and it is important that they do
>this on their own. This is one of the two typical fundamental flaws of
>guideline documents, they distract.

In the previous incarnation of the guidelines documents of QA Framework, we 
actually had a two-fold approach.  A checkpoint's statement -- it's "title" 
-- was typically an imperative voice statement.  But the checkpoint's 
statement was non-normative.  The normative content within the checkpoint 
was given as one or more verifiable requirements (using RFC2119 keywords) 
directed at the target -- e.g., a specification, or a test suite, or a WG's 
QA Process Document.  ("The specification *must* contain...", or "The 
results reporting facility of the test suite *must* ...blah...")

We (QAWG) took this approach in order to balance the tension between 
human-friendly readability, and objective verifiability.

What do you think of that approach?

>The other flaw is that they do not
>tell what *not* to do, while it is natural to learn from mistakes.
>
>Concerning translations, the choice is not as simple as you put it.

So I see.  My grasp of the languages is probably just enough for me to be 
offensive!  Thanks for the careful clarification...

>As
>I've already pointed out, the document typically does not directly
>address the reader and less so personally. It is uncommon to address
>readers of mailing list or usenet postings, participants in an IRC
>discussion, etc. using the formal german "sie" (and if you do it would
>likely be percieved as offensive) hence using it in a translation of a
>web document often feels odd for the translator. As does using the less
>formal "du" as one does not address the reader personally. Whatever you
>decide, you will probably be uncomfortable with it. You can try to avoid
>the trouble through indirection (e.g., translating "one should" rather
>than "you should") but that would end up in some odd results and you
>would be uncomfortable with it since you basically changed the text...
>
>You would have the same problem in the
>
>   "Specify the character encoding of the document."
>
>case, a german translation might be
>
>   "Gib die Zeichenkodierung des Dokuments an."
>
>or rather
>
>   "Gib die Zeichenkodierung des Dokuments an!"
>
>as it really is an imperative form, but even though this lacks a "du" it
>is still less formal than
>
>   "Geben Sie die Zeichenkodierung des Dokuments an!"
>
>which sounds rather unfriendly.
>
>It does not seem to add any value to directly address the reader in a TR
>(it rather indicates some flaw in it, IMO) and it feels much better not
>having to deal with it in a translation, hence I suggested the text to
>this effect in the W3C Manual of Style. <http://www.w3.org/TR/xhtml1/>
>uses "you" in Appendix C, ("This appendix summarizes design guidelines
>for authors who wish their XHTML documents to render on existing HTML
>user agents.") It should be obvious that it is not necessarily the
>authors obligation to make the suggested modifications, it might well be
>an editor or a conversion tool. Of course, when authors use these tools
>they indirectly make these modifications, but addressing them *directly*
>for something they do *indirectly* does not make much sense to me.

Thanks again.

By the way, let me ask in closing about "expected response".  Your comments 
will get attention in the QAWG deliberations as we move forward with 
revised ("Lite") QA Framework.  Do you want any further formal 
response?  E.g., do you want us to queue a formal issue and resolve 
it?  (Yes ... you are still awaiting replies to your five CR 
issues.  Soon!  We are now working on closing out and replying to all 
submitted CR issues.)

Regards,
-Lofton.

Received on Monday, 26 April 2004 10:43:47 UTC