all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Vincent Belaïche" <vincent.b.1@hotmail.fr>
To: Jean-Christophe Helary
	<jean.christophe.helary@traductaire-libre.org>,
	Eli Zaretskii <eliz@gnu.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
	"stefankangas@gmail.com" <stefankangas@gmail.com>
Subject: RE: Where to contribute manual translations ? (Re: Emacs-devel Digest, Vol 238, Issue 29)
Date: Fri, 29 Dec 2023 22:58:26 +0000	[thread overview]
Message-ID: <PAXP192MB16085595A006D9F71B18398C849DA@PAXP192MB1608.EURP192.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <B1026FD6-ED97-4FAE-A581-EFD954218527@traductaire-libre.org>

[-- Attachment #1: Type: text/plain, Size: 4174 bytes --]

Dear Jean-Christophe,

I had a look at your git repo, and I also watched your presentation about OmegaT. I realize that all the manual translations that you have are po files that are output by OmegaT as a sequence of individual segment translations. I understand that some tool will then reassemble those segment to rebuild the Texinfo file, that can then be compiled to the usuer manuel.

My translation of SES manual to French is a « hand-made » translation (as opposed to computer-aided), so it is a plain Texinfo file which I directly edited with an editor (it was Emacs, but any editor, and even MSWord used as a text editor could have been used). Therefore I am not sure that your repo is the best place for me. For the time being I will therefore have it on the Emacs repo, when the conversation here converges on the right place and name.

I don't know how you can get my translation and use it in your OmegaT framework as the splitting into segments + segment naming is not done. Also, I am not sure that I want to install and learn how to use OmegaT, as I am not a professional translator, and my aim was not so much as to produce a translation (although I have no doubt that it will be useful), but the side products of translating, that is improve the manual quality and my knowledge and understanding. That is the same reason for which I translated to French the Unofficial LaTeX manual, that allowed plenty of minor improvements on the manual (both English & French versions).

   Vincent.
________________________________
De : Jean-Christophe Helary <jean.christophe.helary@traductaire-libre.org>
Envoyé : vendredi 29 décembre 2023 15:21
À : Eli Zaretskii <eliz@gnu.org>
Cc : emacs-devel@gnu.org <emacs-devel@gnu.org>; vincent.b.1@hotmail.fr <vincent.b.1@hotmail.fr>; stefankangas@gmail.com <stefankangas@gmail.com>
Objet : Re: Where to contribute manual translations ? (Re: Emacs-devel Digest, Vol 238, Issue 29)



> On Dec 29, 2023, at 15:48, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Date: Fri, 29 Dec 2023 01:23:40 +0000
>> From: Jean-Christophe Helary <jean.christophe.helary@traductaire-libre.org>
>> Cc: vincent.b.1@hotmail.fr, stefankangas@gmail.com, eliz@gnu.org
>>
>>>> Another question : how to internationalize docstrings ? IMHO it would
>>>> be great if the docstring could have some info manual anchor in it, and
>>>> one could display it from the currently selected language manual.
>>>> Besides, reading docstring from manual via some anchor is basically
>>>> what Calc does with some kitchen tricks.

>> Eli answered that.

>> There is also a different issue, that comes before translation, it is
>> fixing user facing strings, so that they can eventually be translated
>> one day. I also made a presentation on that at EmacsConf 2022:
>> https://emacsconf.org/2022/talks/localizing/
>
> I believe this issue was also raised in the discussions whose pointers
> I provided.

You’re correct.

> AFAIR, this issue is a much harder one, since manipulating such strings
> is pervasive in Emacs, and mostly in Lisp, not in C.

My experience with package.el, as I suggested in the presentation, is
that knowledge of Emacs Lisp can be obtained while checking the
strings. There are not that many functions that act on strings, so it’s
relatively easy to see what’s going on in the code and how the strings
are produced.

The slightly more difficult part is to fix the strings so that even if
there is a little redundancy, there are not smart tricks on language
“objects” (like “concatenate an s if such variable is bigger than 1”),
because that involves writing some real and correct elisp :)

But it’s a fun and very practical way to learn some parts of Elisp.

As for creating a process for actually localizing the strings and
displaying them in the locale language, you are right to say that we
concluded that it was a much harder issue, since we’d have to come up
with a lisp-specific system, if my memory is correct.

--
Jean-Christophe Helary @jchelary@emacs.ch
https://traductaire-libre.org
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/


[-- Attachment #2: Type: text/html, Size: 6610 bytes --]

  reply	other threads:[~2023-12-29 22:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.35.1703782806.25325.emacs-devel@gnu.org>
2023-12-29  0:24 ` Where to contribute manual translations ? (Re: Emacs-devel Digest, Vol 238, Issue 29) Jean-Christophe Helary
2023-12-31  3:15   ` Richard Stallman
2023-12-31  3:29     ` Jean-Christophe Helary
2024-01-02  3:20       ` Richard Stallman
2024-01-02  3:24         ` Stefan Kangas
2024-01-02  3:32         ` Eli Zaretskii
2023-12-31  7:38     ` Eli Zaretskii
2023-12-29  1:23 ` Jean-Christophe Helary
2023-12-29  6:48   ` Eli Zaretskii
2023-12-29 14:21     ` Jean-Christophe Helary
2023-12-29 22:58       ` Vincent Belaïche [this message]
2023-12-30  1:33         ` Jean-Christophe Helary
2023-12-29  7:10   ` Emanuel Berg

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=PAXP192MB16085595A006D9F71B18398C849DA@PAXP192MB1608.EURP192.PROD.OUTLOOK.COM \
    --to=vincent.b.1@hotmail.fr \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jean.christophe.helary@traductaire-libre.org \
    --cc=stefankangas@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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.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.