LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [GIT PULL/RESEND] kernel message catalog patches
Date: Mon, 27 Oct 2008 15:36:53 -0400	[thread overview]
Message-ID: <20081027193653.GC23111@mit.edu> (raw)
In-Reply-To: <alpine.LFD.2.00.0810270906520.3386@nehalem.linux-foundation.org>

On Mon, Oct 27, 2008 at 09:10:56AM -0700, Linus Torvalds wrote:
> 
> I do agree. Another issue is that quite often the actual line to be 
> printed is likely fairly short, and often in an error path (so it's 
> indented and in an inconvenient place), but the explanation - even for a 
> _single_ language - may well be pretty involved and long.

It's likely that the explanation would need to be just outside the
containing function, and not in-line where it might need to be deeply
indented. 

And I think we do need separate out the question of multiple langauges
from the explanation in a single canonical language (i.e., English).
Does keeping the explanation just before the containing function mean
that it's "so far away" that it might as well be kept completely
outside of the kernel?  I don't think so, but it's probably not worth
a huge amount of effort debating it; tools for keeping an external
database in sync is a pain, but they've certainly been done before for
related problems (especially in the case of translations, where they
would have to be done that way anyway).

     	  	  	      	   	    - Ted


      parent reply	other threads:[~2008-10-27 19:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16 14:50 [GIT PULL] " Martin Schwidefsky
2008-10-17  7:59 ` Martin Schwidefsky
2008-10-21  9:21   ` [GIT PULL/RESEND] " Heiko Carstens
2008-10-23 15:35     ` Linus Torvalds
2008-10-23 21:04       ` Heiko Carstens
2008-10-23 21:37         ` Linus Torvalds
2008-10-24 15:50           ` Heiko Carstens
2008-10-26 19:26           ` Martin Schwidefsky
2008-10-26 19:12             ` Linus Torvalds
2008-10-27 10:01               ` Martin Schwidefsky
2008-10-27 15:05                 ` Linus Torvalds
2008-10-27 15:52                   ` Martin Schwidefsky
2008-10-27 16:19                     ` Theodore Tso
2008-10-27 16:27                       ` Randy Dunlap
2008-10-28  8:25                         ` Martin Schwidefsky
2008-10-27 16:03                   ` Alan Cox
2008-10-27 16:10                     ` Linus Torvalds
2008-10-27 16:35                       ` Alan Cox
2008-10-27 19:36                       ` Theodore Tso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081027193653.GC23111@mit.edu \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [GIT PULL/RESEND] kernel message catalog patches' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).