From mboxrd@z Thu Jan 1 00:00:00 1970 From: julien lepiller Subject: Re: [WIP] localize guix.texi Date: Mon, 05 Mar 2018 10:58:38 +0100 Message-ID: <404dcea54807bc3ede5ea11559909f99@lepiller.eu> References: <20180219233437.4d709181@lepiller.eu> <20180302230738.13736-1-julien@lepiller.eu> <87y3j6dh4n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esmtM-0001uO-0D for guix-devel@gnu.org; Mon, 05 Mar 2018 04:58:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1esmtI-0006W1-37 for guix-devel@gnu.org; Mon, 05 Mar 2018 04:58:48 -0500 Received: from lepiller.eu ([89.234.186.109]:43082) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1esmtH-0006Tr-Q8 for guix-devel@gnu.org; Mon, 05 Mar 2018 04:58:44 -0500 Received: from webmail.lepiller.eu (static-176-182-42-79.ncc.abo.bbox.fr [176.182.42.79]) by lepiller.eu (OpenSMTPD) with ESMTPSA id b29fcd16 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Mon, 5 Mar 2018 10:00:30 +0000 (UTC) In-Reply-To: <87y3j6dh4n.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Le 2018-03-05 10:08, ludo@gnu.org a écrit : > Hi, > > Julien Lepiller skribis: > >> Hi, this new version of the patch takes your feedback into account. I >> tried >> to put guix.fr.texi in dist_info_TEXINFOS, but automake didn't >> generate the >> rules for building guix.fr.info in that case. >> >> I don't like the fact that both the po and texi files are commited and >> will >> be changed together whenever someone makes a change in the manual. > > I think this can be addressed by adding: > > PO_DEPENDS_ON_POT = no > > in ‘Makevars’. This variable is documented like this: > > --8<---------------cut here---------------start------------->8--- > # This tells whether or not to regenerate a PO file when $(DOMAIN).pot > # has changed. Possible values are "yes" and "no". Set this to no if > # the POT file is checked in the repository and the version control > # program ignores timestamps. > PO_DEPENDS_ON_POT = yes > --8<---------------cut here---------------end--------------->8--- Well, since there's no pot file, it doesn't really help. > >> The French translation is just the beginning: I translated only the >> Introduction >> and the Installation pages. Also, I used the po file to add the >> @documentlanguage macro to change the texinfo strings to French (like >> "see", >> "next page", "up", etc). > > Sounds good. I think ‘makeinfo --html’ would also need to run in fr_FR > locale no? Or does @documentlanguage take care of everything, > including > strings automatically added by makeinfo, such as those that appear at > the top of each HTML page? @documentlanguage is enough > >> There's an issue with changes that add references: when that happens, >> the >> default translation would be the English version, so the reference >> would be >> to the English name (for instance, @pxref{Invoking guix package}), >> resulting >> in a build failure when the name has been changed (for instance >> "Invoquer guix package" in French). I would like to be able to >> localize the >> section name because it appears in link names. Any ideas? > > No idea. Can po4a help with that? It doesn't seem so. But that may be an improvement of po4a. > > At worst, if .po files are committed and not systematically generated, > we can let translators handle this before they commit? I don't understand? The issue is when translators are not involved. IIUC in texinfo, the section name (reference) and title (displayed) are the same, so section names have to be translated. When someone makes a change to the English manual and adds a reference to an existing section, po4a cannot generate a translation, so it will leave it as is. So we will get a reference to an invalid section in the translated manuals and they will refuse to build. There is enough information in the po file though, so I think po4a can be improved (or we could add our own script for that). Thank you! > > Thanks, > Ludo’.