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).

> 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/