From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH] Longtable continuation strings customizable Date: Mon, 28 Oct 2013 10:28:00 +0100 Message-ID: <87txg1agnz.fsf@gmail.com> References: <87y55fb0kf.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vaj72-0006UW-GJ for emacs-orgmode@gnu.org; Mon, 28 Oct 2013 05:27:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vaj6t-0003pK-Kg for emacs-orgmode@gnu.org; Mon, 28 Oct 2013 05:27:52 -0400 Received: from mail-wg0-x229.google.com ([2a00:1450:400c:c00::229]:45154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vaj6t-0003pE-ED for emacs-orgmode@gnu.org; Mon, 28 Oct 2013 05:27:43 -0400 Received: by mail-wg0-f41.google.com with SMTP id b13so3159481wgh.2 for ; Mon, 28 Oct 2013 02:27:42 -0700 (PDT) In-Reply-To: (Thomas S. Dye's message of "Sun, 27 Oct 2013 06:52:56 -1000") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Thomas S. Dye" Cc: Org-mode , Carsten Dominik Hello, tsd@tsdye.com (Thomas S. Dye) writes: > I think there are two axes of variation here: > > 1) internationalization, and > 2) style guides, e.g., for a particular journal, Chicago Manual, etc. > > IIUC, hardcoding and org-export-dictionary solve 1) but not 2). > > In my experience, variation in 2) is idiosyncratic, though I haven't > looked specifically at table continuation lines. > > The user can solve both 1) and 2) with customizable continuation > strings, so it might be best to stay on this path instead of hardcoding > and internationalization in org-export-dictionary. I agree customization is more powerful here (although it means that all non-English Org users will need to change it), but so it is for every other multilingual string. Since we didn't choose to make multilingual strings customizable, I find it strange that this particular one is. Also, I you can use a filter to modify that string and make it comply to a specific style, if needed. IOW, you also get 1) and 2) with the `org-export-dictionary' way, with 1) being more user-friendly and 2) more difficult than in the current way. Am I missing something? Regards, -- Nicolas Goaziou