From: Hubert Lombard <contact@hubert-lombard.website>
To: "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: Some (little) problems about contributing to the translation of guix-manual
Date: Fri, 30 Oct 2020 10:18:49 +0100 [thread overview]
Message-ID: <20201030101849.24942621@hubert-lombard.website> (raw)
In-Reply-To: <87361w7g59.fsf@gmail.com>
Hi, Miguel and help-guix!
Le Fri, 30 Oct 2020 00:42:58 +0100,
Miguel Ángel Arruga Vivas <rosen644835@gmail.com> a écrit :
> Hi!
>
> Hubert Lombard <contact@hubert-lombard.website> writes:
> > Hi, Julien and help-guix :-)
> >
> > Le Thu, 29 Oct 2020 15:17:44 -0400,
> > Julien Lepiller <julien@lepiller.eu> a écrit :
> [...]
> >> Actually, I just had a look at the file you created. There are
> >> multiple issues with it. Remember that the text is in texinfo
> >> format, so anything of the form @command{content} is a texinfo
> >> command. If you translate it, it might have unexpected effects
> >> (not able to compile, …).
> [...]
> > (while Poedit told me that there were no errors in the translation
> > :-)
>
> It's possible that poedit uses msgfmt underneath to check the
> translation, so it only will warn you you about newlines at the end of
> the string when the original doesn't have it and things like that, but
> unfortunately not about the texinfo syntax. And about the tags:
>
> - @example/@lisp: Its a code fragment used to show something to the
> reader. The comments usually should be translated, even though some
> words may reference API or other code names outside the example, so
> it can be tricky. Usually the code can be "adapted" in varying
> degree; sometimes you can translate almost everything and only the
> keywords of the language stay the same keeping the same semantics,
> but lots of times you cannot change almost any letter as everything
> are API identifiers and changing it would modify the semantics of the
> example.
>
> - @var: It indicates a reference to something that can be
> provided/modified by the end-user, and usually its content can be
> translated, always matching the translation used in all its
> references, and, maybe some @example/@lisp code it references.
>
> - @code, @command, @env, @file and @option: They indicate text with
> some kind of meaning to the computer, either API identifiers or code
> fragments (@code), commands that could be executed (@command),
> environment variables (@env), file references (@file) or options for
> the executable(s) that the manual is written for (@option). Its
> contents shouldn't be translated, unless they really refer to an
> example that has already been adapted to the language.
>
> - @indicateurl, @ref, @xref and @pxref: They indicate links to other
> documents (@indicateurl), or to other sections of the manual itself
> (@?*ref). These are the trickiest from my point of view. As Julien
> explained, these identifiers are changed automatically during the
> manual translation generation, but not all parameters (think of them
> as function calls) are really the same. The first one shouldn't be
> translated, and usually it's the only one, neither the external
> references (the ones with 5 parameters) as there is no translation
> for most of GNU manuals. Only the second and third parameters when
> they are the last ones should be translated. The tag @indicateurl
> also has this semantics. As an example from my translation, the
> original text
>
> "@pxref{fallback-option,, common build option @option{--fallback}}"
>
> Translates to this in spanish:
>
> "@pxref{fallback-option,, opción común de construcción
> @option{--fallback}}"
>
> I think these should be the most common ones, at least the ones from
> the top of my head.
>
> Or, like the manual could say: @xref{Top,,, texinfo, GNU Texinfo} or
> @indicateurl{https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html},
> for more information about these tags. ;-)
These explanations are going to be very useful, I copied them in my personal documentation.
in order to be able to study them in more detail later :-)
> [...]
> >> If you're not working on that file right now, I can take care of
> >> fixing these issues and give you control over the file again
> >> tomorrow morning.
>
> I have to say thank you too, even though I'm not a French user,
> because these are the things make this community really great. :-)
Yes, by the way, Julien has fixed the problems since yesterday and made the .po valid!
I hope to be able to meet you all soon at an event ;-)
> > It's very nice of you, I'd like you to take care of it if you
> > can. Tomorrow morning, I will study carefully what you will have
> > done. Really, thank you Julien!
> >
> > I also read your answers on git clone, I'll take good note of them
> > too ;)
>
> Tomorrow I'll be available some time on IRC too, usually by the
> initial letters of my name. You can check on the channel too if you
> have any doubt or issue.
>
> > Well, I'm going to go rest a little bit!
> >
> >> Thanks!
> >
> > Thanks to you!
>
> Good night, and thanks to you, both, again! :-)
>
> And just one comment from an older mail:
>
> Hubert Lombard <contact@hubert-lombard.website> writes:
> > On Tue, 27 Oct 2020 20:42:05 +0100
> > Miguel Ángel Arruga Vivas <rosen644835@gmail.com> wrote:
> >> I'm sure you'll advance more, just wanted to ensure. :-)
> >
> > Yes, I can advance enough for now, at the end of this day, I hope to
> > have 88% or more translated. Don't worry for your "I'm sure", I had
> > understood ;-)
>
> Sorry, and thanks for your understanding. I was trying to write
> something to encourage you somehow, but I left it to the end as I
> didn't find the words... and I sent it by mistake. :-(
Don't worry, I also feel the fervor in which you are involved and your answers on the translation and git clone were very helpful to me.
I will be able to take some time to assimilate all this...
See you soon
--
Hubert
next prev parent reply other threads:[~2020-10-30 9:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 19:07 Some (little) problems about contributing to the translation of guix-manual Hubert Lombard
2020-10-26 19:16 ` Julien Lepiller
2020-10-26 22:04 ` Hubert Lombard
2020-10-26 21:40 ` Miguel Ángel Arruga Vivas
2020-10-27 8:38 ` Hubert Lombard
2020-10-27 19:42 ` Miguel Ángel Arruga Vivas
2020-10-27 19:44 ` Miguel Ángel Arruga Vivas
2020-10-28 15:28 ` Hubert Lombard
2020-10-29 18:32 ` Hubert Lombard
2020-10-29 19:00 ` Julien Lepiller
2020-10-29 19:17 ` Julien Lepiller
2020-10-29 21:21 ` Hubert Lombard
2020-10-29 23:42 ` Miguel Ángel Arruga Vivas
2020-10-30 9:18 ` Hubert Lombard [this message]
2020-10-30 0:00 ` Julien Lepiller
2020-10-30 8:29 ` Hubert Lombard
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201030101849.24942621@hubert-lombard.website \
--to=contact@hubert-lombard.website \
--cc=help-guix@gnu.org \
--cc=rosen644835@gmail.com \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).