all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: julien lepiller <julien@lepiller.eu>
To: guix-devel@gnu.org
Subject: Re: [WIP] localize guix.texi
Date: Mon, 05 Mar 2018 10:58:38 +0100	[thread overview]
Message-ID: <404dcea54807bc3ede5ea11559909f99@lepiller.eu> (raw)
In-Reply-To: <87y3j6dh4n.fsf@gnu.org>

Le 2018-03-05 10:08, ludo@gnu.org a écrit :
> Hi,
> 
> Julien Lepiller <julien@lepiller.eu> 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’.

  reply	other threads:[~2018-03-05  9:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19 22:34 [WIP]: localize guix.texi Julien Lepiller
2018-02-19 22:45 ` Julien Lepiller
2018-03-02 13:31   ` Ludovic Courtès
2018-03-02 15:57     ` Gábor Boskovits
2018-03-02 23:07 ` [WIP] " Julien Lepiller
2018-03-02 23:07   ` [PATCH 1/3] gnu: doc: Alloc documentation to be translated Julien Lepiller
2018-03-05  9:10     ` Ludovic Courtès
2018-03-28 21:05       ` Julien Lepiller
2018-03-31 21:33         ` Ludovic Courtès
2018-03-02 23:07   ` [PATCH 2/3] gnu: guix: Add po4a input Julien Lepiller
2018-03-05  9:10     ` Ludovic Courtès
2018-03-05  9:08   ` [WIP] localize guix.texi Ludovic Courtès
2018-03-05  9:58     ` julien lepiller [this message]
2018-03-05 11:00       ` Ludovic Courtès

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=404dcea54807bc3ede5ea11559909f99@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=guix-devel@gnu.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.