Discussion for some French translations

[dbitouze]

Many thanks for this very nice, interesting and promising package!

Most of the French wordings are perfectly translated (congratulations!) but others look a bit strange IMHO. Since I'm unsure of what would be the best translations, I open this issue in order other French-speaking people could give their opinion so that we can reach a consensus.

Controversial translations

Here are the translations that IMHO need to be discussed:

"Table" vs "Tableau"

type = table ,
  gender = f ,
  Name-sg = Table ,
  name-sg = table ,
  Name-pl = Tables ,
  name-pl = tables ,

"Table" is the translation used by e.g. babel-french but many users feel a bit uncomfortable with this translation since "Tableau" is much more common.

"Point" vs "Item"

type = item ,
  gender = m ,
  Name-sg = Point ,
  name-sg = point ,
  Name-pl = Points ,
  name-pl = points ,

"Point" is maybe appropriate, but "Item" is also a French word which not so uncommon and relies clearly on the LaTeX command \item.

"Démonstration" vs "Preuve"

type = proof ,
  gender = f ,
  Name-sg = Démonstration ,
  name-sg = démonstration ,
  Name-pl = Démonstrations ,
  name-pl = démonstrations ,

"Démonstration" is clearly an appropriate translation of "Proof" but "Preuve" is also appropriate, understandable, more directly derived from "Proof"... and shorter.

"Liste" vs "Listing" vs "Code"

type = listing ,
  gender = f ,
  Name-sg = Liste ,
  name-sg = liste ,
  Name-pl = Listes ,
  name-pl = listes ,

I guess "Liste" would be confusing for French-speaking people, as they wouldn't have in mind a printed source code. Conversely, "Listing" is a French word less confusing. Maybe "Code" could also be an option.

Non-controversial translations

I guess the following translations don't need any discussion:

type = book ,
  gender = m ,
  Name-sg = Livre ,
  name-sg = livre ,
  Name-pl = Livres ,
  name-pl = livres ,

type = part ,
  gender = f ,
  Name-sg = Partie ,
  name-sg = partie ,
  Name-pl = Parties ,
  name-pl = parties ,

type = chapter ,
  gender = m ,
  Name-sg = Chapitre ,
  name-sg = chapitre ,
  Name-pl = Chapitres ,
  name-pl = chapitres ,

type = section ,
  gender = f ,
  Name-sg = Section ,
  name-sg = section ,
  Name-pl = Sections ,
  name-pl = sections ,

type = paragraph ,
  gender = m ,
  Name-sg = Paragraphe ,
  name-sg = paragraphe ,
  Name-pl = Paragraphes ,
  name-pl = paragraphes ,

type = appendix ,
  gender = f ,
  Name-sg = Annexe ,
  name-sg = annexe ,
  Name-pl = Annexes ,
  name-pl = annexes ,

type = subappendix ,
  gender = f ,
  Name-sg = Annexe ,
  name-sg = annexe ,
  Name-pl = Annexes ,
  name-pl = annexes ,

type = page ,
  gender = f ,
  Name-sg = Page ,
  name-sg = page ,
  Name-pl = Pages ,
  name-pl = pages ,
  rangesep = {\textendash} ,

type = line ,
  gender = f ,
  Name-sg = Ligne ,
  name-sg = ligne ,
  Name-pl = Lignes ,
  name-pl = lignes ,

type = figure ,
  gender = f ,
  Name-sg = Figure ,
  name-sg = figure ,
  Name-pl = Figures ,
  name-pl = figures ,

type = footnote ,
  gender = f ,
  Name-sg = Note ,
  name-sg = note ,
  Name-pl = Notes ,
  name-pl = notes ,

type = endnote ,
  gender = f ,
  Name-sg = Note ,
  name-sg = note ,
  Name-pl = Notes ,
  name-pl = notes ,

type = note ,
  gender = f ,
  Name-sg = Note ,
  name-sg = note ,
  Name-pl = Notes ,
  name-pl = notes ,

type = equation ,
  gender = f ,
  Name-sg = Équation ,
  name-sg = équation ,
  Name-pl = Équations ,
  name-pl = équations ,
  refpre = {(} ,
  refpos = {)} ,

type = theorem ,
  gender = m ,
  Name-sg = Théorème ,
  name-sg = théorème ,
  Name-pl = Théorèmes ,
  name-pl = théorèmes ,

type = lemma ,
  gender = m ,
  Name-sg = Lemme ,
  name-sg = lemme ,
  Name-pl = Lemmes ,
  name-pl = lemmes ,

type = corollary ,
  gender = m ,
  Name-sg = Corollaire ,
  name-sg = corollaire ,
  Name-pl = Corollaires ,
  name-pl = corollaires ,

type = proposition ,
  gender = f ,
  Name-sg = Proposition ,
  name-sg = proposition ,
  Name-pl = Propositions ,
  name-pl = propositions ,

type = definition ,
  gender = f ,
  Name-sg = Définition ,
  name-sg = définition ,
  Name-pl = Définitions ,
  name-pl = définitions ,

type = result ,
  gender = m ,
  Name-sg = Résultat ,
  name-sg = résultat ,
  Name-pl = Résultats ,
  name-pl = résultats ,

type = remark ,
  gender = f ,
  Name-sg = Remarque ,
  name-sg = remarque ,
  Name-pl = Remarques ,
  name-pl = remarques ,

type = example ,
  gender = m ,
  Name-sg = Exemple ,
  name-sg = exemple ,
  Name-pl = Exemples ,
  name-pl = exemples ,

type = algorithm ,
  gender = m ,
  Name-sg = Algorithme ,
  name-sg = algorithme ,
  Name-pl = Algorithmes ,
  name-pl = algorithmes ,

type = exercise ,
  gender = m ,
  Name-sg = Exercice ,
  name-sg = exercice ,
  Name-pl = Exercices ,
  name-pl = exercices ,

type = solution ,
  gender = f ,
  Name-sg = Solution ,
  name-sg = solution ,
  Name-pl = Solutions ,
  name-pl = solutions ,

[gusbrs]

Many thanks for this very nice, interesting and promising package!

Thanks! I hope you enjoy it!

Most of the French wordings are perfectly translated (congratulations!) but others look a bit strange IMHO.

This is most appreciated. My contact with French is restricted to reading (thus passive), and literature at that, so quite distanced from the kind of vocabulary needed for this task. I did use some packages which translate document elements as a reference (babel, cleveref, translator, translations), but there was only so much I could do. And my criterion here is that it should sound good and be common usage to French speakers, which I'm not. So, as humble as your opinion may be, it is better than mine.

Since I'm unsure of what would be the best translations, I open this issue in order other French-speaking people could give their opinion so that we can reach a consensus.

I'm glad you opened the discussion. Thank you very much. I'll comment on each of your suggestions.

"Table" vs "Tableau"

I knew this one would be contentious. babel sets \tablename to "Table" and \listtablename to "Liste de tableaux". translations and translator follow babel, cleveref uses "Tableau".

My thought here was to follow babel because, in this case, it should match the caption, which is ultimately set by it. If pretty much everyone just changes babel's default here, it might be a case to use "Tableau". But if opinions diverge, I'd stick with babel for the mentioned reason.

"Point" vs "Item"

Point taken :). Funny enough, being myself a native speaker of Portuguese, I've chosen "Item" for it.

"Démonstration" vs "Preuve"

I followed here translator and translations, if I recall. Anyway, I'm less concerned it is directly derived from the English word, than with what is the most common use for French speakers for the purpose. But the length argument is a good one here, "Démonstration" is indeed too damn long.

Edit: I this case, it should be whatever French mathematicians use. It is probably jargon and standard, but I'm not sure which one is correct.

"Liste" vs "Listing" vs "Code"

I was unsure of this one. I like "Listing", and I didn't know it existed in French. "Code" sounds damn good at first sight, and it would be an alternative for several languages. And I almost included a code type in the package. There's only one problem, it is a numberless word, so the plurals don't work and, hence, we'd have to use "Code something", e.g. "Code block" or whatever, in which case, the term sounds less appealing. Anyway, if "Liste" can be confusing, it is a good reason for something else.

Non-controversial translations

Well, if any other French speaker wants to chime in about other translations, it is certainly much welcome.

All in all, I'll suggest the following. For table, I'd need a strong reason do diverge from babel, so if a number of people agree "Tableau" it is indisputably better, I'd consider it. For the remainder suggestions, I'm ready to go with your take, if you do think they represent an improvement. So far you've only told to me they are "controversial", please tell me if you think there is a clear case for them. If you feel some of the cases represent an improvement, beyond being controversial, I'm quite ready to take your opinion over mine. Even if we do so provisionally, pending other French speakers also commenting here, for which I'll leave this issue open for some time.

[gusbrs]

Just adding some information here. I was researching the use of "Démonstration" vs "Preuve" by mathematicians, and searched for French associations of the area. I found the Société Mathématique de France, which provides a couple of LaTeX document classes (smfart.cls and smfbook.cls, at https://smf.emath.fr/publications/instructions-pour-les-auteurs), in which \proofname is set as \def\proofname{D\'emonstration}.

I also found that you, @dbitouze , maintain the gzt classes for La Gazette des Mathématiciens, from the same Association. So, I suppose you can tell us what is the most common use among French mathematicians. :-)

[dbitouze]

On some French LaTeX newsgroup and mailing list, I asked French people to continue the discussion here, but those who answered preferred to discuss there.

Here is what emerged from these discussions (combined with your remarks).

Non-controversial translations

"Table" vs "Tableau"

There is some consensus to not diverge from babel as you suggest. But, instead of hard-coding "Table", it would be better to stick with \tablename which may be redefined by the user (directly or via \frenchtablename provided by babel-french). Here is what I suggest:

\documentclass[french]{article}
\usepackage[T1]{fontenc}
\usepackage{zref-clever}
\usepackage{babel}

\ExplSyntaxOn
\zcLanguageSetup{french}{
  type = table ,
  gender = f ,
  Name-sg = \text_titlecase:n { \tablename } ,
  name-sg = \text_lowercase:n { \tablename } ,
  Name-pl = \text_titlecase:n { \tablename }s ,
  name-pl = \text_lowercase:n { \tablename }s ,
}
\ExplSyntaxOff

\begin{document}

\section{Par défaut}

\begin{table}[ht]
  \centering
  Foo
  \caption{Foo}
  \zlabel{foo}
\end{table}

La \zcref{foo} est très intéressante !

\section{tablename $\to$ Tableau}

\renewcommand*\tablename{Tableau}

\begin{table}[ht]
  \centering
  Bar
  \caption{Bar}
  \zlabel{bar}
\end{table}

Le \zcref{bar} est très intéressant !
\end{document}

IMHO, these ways of doing:

• relying on names defined by babel (and polyglossia) instead of hard-coding,
• relying on \text_titlecase:n, \text_lowercase:n, etc. in order to reduce redundancy,

should be used as well for:

• the other (numbered) names

  \chaptername
  \appendixname
  \figurename
  \tablename
  \partname
  \pagename
  \proofname

• the other languages.

"Point" vs "Item"

No real consensus: it could be "Point", "Item", "Numéro". I suggest letting "Point".

"Démonstration" vs "Preuve"

No real consensus but, as advised before, maybe the best would be to rely on \proofname which may be redefined by the user (directly or via \frenchproofname provided by babel-french). BTW, I don't see any use case for "Proof" since, usually, proofs are unnumbered.

Non-controversial translations

Well, other French speaker wanted to chime in about other translations! :wink:

Page

\pagename instead of "Page" (as advised above) and, for rangesep, \textendash → -:

type = page ,
  gender = f ,
  Name-sg = \text_titlecase:n { \pagename } ,
  name-sg = \text_lowercase:n { \pagename } ,
  Name-pl = \text_titlecase:n { \pagename }s ,
  name-pl = \text_lowercase:n { \pagename }s ,
  rangesep = {-} ,

Footnotes

Though it could be seen as a bit pedantic:

type = footnote ,
  gender = f ,
  Name-sg = Note infrapaginale ,
  name-sg = note infrapaginale ,
  Name-pl = Notes infrapaginales ,
  name-pl = notes infrapaginales ,

(or a better way by using \text_titlecase:n, \text_lowercase:n, etc.)

End notes

type = endnote ,
  gender = f ,
  Name-sg = Note finale ,
  name-sg = note finale ,
  Name-pl = Notes finales ,
  name-pl = notes finales ,

(or a better way by using \text_titlecase:n, \text_lowercase:n, etc.)

Subappendix

Suggested by some people:

type = subappendix ,
  gender = f ,
  Name-sg = Sous-annexe ,
  name-sg = sous-annexe ,
  Name-pl = Sous-annexes ,
  name-pl = sous-annexes ,

(or a better way by using \text_titlecase:n, \text_lowercase:n, etc.)

Paragraph

I don't see the point for (sub)paragraph: just as for (sub)subsection, the reader of the document just doesn't care the paragraph he's interested in, has been introduced by the author with a \paragraph command. IMHO, a single "Section" name is enough for ((sub)sub)section and (sub)paragraph (AKA ((sub(sub(sub)))sub)section).

[gusbrs]

On some French LaTeX newsgroup and mailing list, I asked French people to continue the discussion here, but those who answered preferred to discuss there.

Here is what emerged from these discussions (combined with your remarks).

Thank you very much for reaching out to other people and bringing a summary of it here.

Well, other French speaker wanted to chime in about other translations! :wink:

This is great and appreciated.

I'll comment on each case below, but a general issue first, relative to the general suggestion of using babel set variables to populate the dictionaries. This is one thing I had considered, and eventually I have decided not to share plumbing with babel/polyglossia. Doing so would complicate things quite considerably and, though admittedly there would be some gain, I don't think it is large enough to grant it. I don't mean to say I know for sure this is the best decision, but I have put quite some thought into it, and have made a call about it. I'd like to stick to it, at least until this is proven to bring more problems than it solves. In particular, the current design of the package allows for the lang option to receive values current, main or an arbitrary language, and this can also be set locally. Given that the variables set by babel would only correspond to the current language, it would be quite immediate to break the current structure.

Besides, relying on a single variable to generate four cases is not sufficiently general. For example, not necessarily adding an s to the end is sufficient to generate a plural ("table"/"tableau" is actually a good example). Not to mention noun declension.

In other words, by design, things should be smooth by default, but if you choose to change, e.g. \tablename, it is expected that you also set corresponding names for zref-clever:

\addto\captionsfrancais{%
   \renewcommand*\tablename{Tableau}%
}
\zcLanguageSetup{french}{
  type = table ,
    gender = m ,
    Name-sg = Tableau ,
    name-sg = tableau ,
    Name-pl = Tableaux ,
    name-pl = tableaux ,
}

This is some setup required, but I don't think this should be a big deal, since it would be done only once in the preamble. And in most cases would not be needed at all.

"Table" vs "Tableau"

I'll stick to "Table" then, following babel.

"Point" vs "Item"

Ok, "Point" it is.

"Démonstration" vs "Preuve"

I'll leave it to "démonstration" for the time being then.

Btw, I'm not a mathematician, but if by "usually" you mean "never" (or "almost never"), I might just drop the type. There are a number of types provided in the dictionaries which do not have any counter association by default, they are just there available for the convenience, in case someone decides to use them. This is one of them. It doesn't do any harm, but if its use is just too exceptional, we might just leave it out.

"Liste" vs "Listing" vs "Code"

Where there any suggestions on this one? As far as I can tell, the "least bad" would be "listing", is that your thought too?

Page

\textendash → -

Ah! Good typographical convention catch. I'll change it.

Footnotes and End notes

Well, I don't know of the usage in French, but indeed "Note infrapaginale" sounds heavy to me. But if you're sure, I'll change it. Please confirm. For endnotes, I agree they may require some more "explanation" since they are not within immediate reach.

Subappendix

I don't disagree with the translation, of course. But this sounds more of a consistency issue. Why would "subapendix" be called "sous-annexe" when a "subsection" is called "section"? As a matter of fact, this is my fault. I don't recall why I added the subappendix type in the first place (probably some remnant of an intermediate state for the appendix package support). I'll think of it and, if the later is indeed the case, I might drop the type altogether.

Paragraph

This is indeed debatable, but less an issue for the dictionary than one for the countertype setup. I think it makes sense to distinguish paragraph, but I don't have a strong opinion here. And I don't expect many people to keep numbering as deep as pararagraphs to start with. But changing it is a matter of:

\zcsetup { countertype = { paragraph = section , subparagraph = section } }

But, beyond French usage here, do you think this would be a better default?

Again, thank you very much for your input and for going out of your way to seek other people's opinion on this.

[gusbrs]

I've taken a look at the discussions at GUTenberg and fr.comp.text.tex (https://groups.google.com/g/gut_fr/c/rNLm6weGcyg and https://groups.google.com/g/fr.comp.text.tex/c/Fa11Tf6MFFs) and I have some comments which may be useful or perhaps of interest.

The first thing I noticed is that there appeared to be an implicit presumption that its hard to escape from the built-in dictionary values. In fact, the built-in dictionaries are just the defaults, the reference types are fully configurable (at least to the same extend as the built-in dictionaries are able to). True, one can always go with ⟨terme préféré⟩~\zref{⟨label⟩} or ⟨terme préféré⟩~\zcref[noname]{⟨label⟩} for an occasional local special case. But one should not need to resort to them just because they don't like the dictionary defaults. In this case, it is just a matter of configuring the type to other values with \zcLanguageSetup or \zcRefTypeSetup. The defaults are expected to be reasonable, and are hopefully useful to many, but nobody is bound to them in any way.

Second, the case of footnotes. In this regard, it is important to note that the reference types in the dictionaries are not equally important. On a first level, there are types created to cater for counters underlying LaTeX (kernel) or standard classes document elements: sectioning, table, figure, footnote, and so on. Second, types created for the purpose of handling elements created by some popular packages, e.g. endnote. Third, some types which I have included for presumed common use cases for convenience, and which might be leveraged by the user if they so want to, but which are not associated to anything by default. An example of the later is the note type. In particular, I have created this for the sake of some languages for which the best passing term is specific for "footnotes" (English, German), and I thought it might be useful to have a generic type as well, thus "notes". But, my initial thought at least, is that for languages for which a generic term would be fit for the footnote type (French among them, so I thought), there would be no harm in them being equal. In sum, what I'm trying to say is: choose the best term for the footnote type for the sole sake of how you'd like to refer to this document element, and not to "distinguish it from the note type" or to "educate the masses". The note type is of little consequence, the footnote, quite the contrary. I do think "note infrapaginale" is a poor choice but, that said, it is up to you folks.

Third, it did not appear in the discussions, one of the features of the package which I think (and hope) might be particularly interesting for French speakers (and other languages with inflected articles), which is the nudge option. This feature offers some guard against the occasional "aberrations" the kind of automation zref-clever provides may indeed sometimes produce. (Those interested may want to take a look at the "Options" and "Internationalization" sections of the manual).

Finally, I'd like to thank very much everyone who weighted in those threads, and particularly to @dbitouze for conducing them. That was much appreciated.

[dbitouze]

I've taken a look at the discussions at GUTenberg and fr.comp.text.tex (https://groups.google.com/g/gut_fr/c/rNLm6weGcyg and https://groups.google.com/g/fr.comp.text.tex/c/Fa11Tf6MFFs) and I have some comments which may be useful or perhaps of interest.

Congratulations for the investigations and the pain of reading French! :smile:

The first thing I noticed is that there appeared to be an implicit presumption that its hard to escape from the built-in dictionary values. In fact, the built-in dictionaries are just the defaults, the reference types are fully configurable (at least to the same extend as the built-in dictionaries are able to). True, one can always go with ⟨terme préféré⟩~\zref{⟨label⟩} or ⟨terme préféré⟩~\zcref[noname]{⟨label⟩} for an occasional local special case. But one should not need to resort to them just because they don't like the dictionary defaults. In this case, it is just a matter of configuring the type to other values with \zcLanguageSetup or \zcRefTypeSetup. The defaults are expected to be reasonable, and are hopefully useful to many, but nobody is bound to them in any way.

OK. IMHO, the objection was for occasional local special cases, but good to know.

Second, the case of footnotes. In this regard, it is important to note that the reference types in the dictionaries are not equally important. On a first level, there are types created to cater for counters underlying LaTeX (kernel) or standard classes document elements: sectioning, table, figure, footnote, and so on. Second, types created for the purpose of handling elements created by some popular packages, e.g. endnote. Third, some types which I have included for presumed common use cases for convenience, and which might be leveraged by the user if they so want to, but which are not associated to anything by default. An example of the later is the note type. In particular, I have created this for the sake of some languages for which the best passing term is specific for "footnotes" (English, German), and I thought it might be useful to have a generic type as well, thus "notes". But, my initial thought at least, is that for languages for which a generic term would be fit for the footnote type (French among them, so I thought), there would be no harm in them being equal. In sum, what I'm trying to say is: choose the best term for the footnote type for the sole sake of how you'd like to refer to this document element, and not to "distinguish it from the note type" or to "educate the masses". The note type is of little consequence, the footnote, quite the contrary. I do think "note infrapaginale" is a poor choice but, that said, it is up to you folks.

OK, I see. So I guess we can let (n|N)ote(s) for both type = footnote, type = endnote and type = note.

Third, it did not appear in the discussions, one of the features of the package which I think (and hope) might be particularly interesting for French speakers (and other languages with inflected articles), which is the nudge option. This feature offers some guard against the occasional "aberrations" the kind of automation zref-clever provides may indeed sometimes produce. (Those interested may want to take a look at the "Options" and "Internationalization" sections of the manual).

Indeed (I must admit I didn't read carefully the whole documentation yet). Maybe some examples in the documentation would be helpful.

Finally, I'd like to thank very much everyone who weighted in those threads, and particularly to @dbitouze for conducing them. That was much appreciated.

You're welcome.

[gusbrs]

OK, I see. So I guess we can let (n|N)ote(s) for both type = footnote, type = endnote and type = note.

Done. Thanks again.

Indeed (I must admit I didn't read carefully the whole documentation yet). Maybe some examples in the documentation would be helpful.

Admittedly, it is somewhat hard to provide self-sufficient examples of it, since it is more of a "workflow" kind of feature. But the Internationalization section (roughly the second half of it) of the manual has a detailed description of the intended use of the feature, with some small examples included.

[flagarde]

Hi,

Concerning the "Démonstration" vs "Preuve" I think Preuve is more related to material things and it's closer to "evidence" in english while demontsration denote more so act or so reasoning to prove something. Both are perfectly fine but I think french mathematicians will use more the "Démonstration" word. Using preuve is an englisism in this context I thinkso you made the good choice.

The Académie française says : Preuve : Vérification d’une opération de calcul, qui se fait généralement par l’opération opposée. La preuve de la division se fait par la multiplication. Preuve par neuf, méthode fondée sur les propriétés arithmétiques du nombre neuf et qui permet de vérifier le résultat d’une multiplication.

Démonstration : Action de démontrer ; résultat de cette action. Démarche rationnelle qui établit la vérité d’une proposition.

So from my understanding the Démonstration is more general and enforce the fact you are doing some reasoning and acting to show the veracity.

As french native speaker I have always heard my teachers say "démonstration" and seen it on french books. The Nicolas Bourbaki group for example always use it.

[gusbrs]

Hi @flagarde , thank you for chiming in! I think "Démonstration" is a keeper indeed, opinions seem to converge. Even when "Preuve" would be formally correct, it seems to be considered an anglicism (which probably is indeed, the interesting bit is how people feel about it), and "Démonstration" is not only more precise but also preferred and commonly used for the purpose at hand, which in this case should match technical/specialized jargon.

[flagarde]

Concerning the other "controversial translations" pointed by @dbitouze :

"Table" vs "Tableau"

Both are perfectly french words and both are recommanded by the Académie française. Tableau is more an everyday word so I would be tempted to use Table as it looks more appropriate for books.

"Point" vs "Item"

Point is more appropriated because the word Item exists in french but don't have the meaning we want in this case. Again the Académie française explicitly point this as englisism in this case "xxe siècle. Emploi substantivé d’item I, par l’intermédiaire de l’anglais où ce mot signifie « numéro, article »." An other alternative would be ÉLÉMENT :

Ce qui entre dans la constitution d’un ensemble.
1. Chaque partie identifiable à l’intérieur d’un ensemble qu’elle contribue à former.

"Liste" vs "Listing" vs "Code"

I agree with @dbitouze that List would be very confusing for a french speaker. However the word listing is not recommanded by the Académie française https://www.dictionnaire-academie.fr/article/DNP0453. And even the meaning of this englisism has not the meaning we want but is related to the action of creating a table using some software. Code or code source would be a better solution as mentioned. The code source solution stress the fact it should be compiled or will generate something or will do something.

[gusbrs]

Hi @flagarde , thanks again for adding to the discussion.

"Table" vs "Tableau"

With respect to this one, it seems clear by now that both would be legitimate choices, and that the preference is divided. In this case, the fact that babel uses "Table" for \tablename is enough reason to keep it for the type here, since it should match the caption text by default. Again, this is just the default, and can be reconfigured for those who prefer it different.

"Point" vs "Item"

That's what we've kept, thanks for bringing further reasons to having done so.

"Liste" vs "Listing" vs "Code"

Here, the consideration by @dbitouze that "Liste" would be confusing was enough for me to drop it. I went with "Listing" as the least bad alternative. But this is admittedly a difficult one, and not just in French. In particular, using "Code" has the problem of it being a numberless word, and thus the plurals don't work (see https://github.com/gusbrs/zref-clever/issues/1#issuecomment-979211870). As far as I can tell, "Code source" would also be affected by the same problem. Would something like "comme on peut voir en Code sources 2 et 4 ..." really sound good in French? I doesn't sound good to me, but perhaps I'm thinking in another language.

Btw, the link you provided, suggests another alternative: "Listage". Is it a good one? Better than "Listings"? (Just asking, not really proposing. If my Portuguese ears can be any reference, this would likely suffer from the same potential confusion as "Liste", though I have gone with "Listagem" for the Portuguese dictionary, which does suffer from the same possible ambiguity as French, as far as I can tell).

From my perspective, the requirements for this one are that it must be a good default to encompass anything which may regularly be included in listing or lstlisting environments. And, in general, we are not looking for the "perfect translation for the English word used for the type" but rather the term a French speaker would commonly use to refer to the document object in question, and a numbered object at that. I make this distinction here because "Code" and "Code source" seem to fit better "what the object contains" than "the object itself". So I'd more naturally think "listings contain source code" than "listings and source codes can be used interchangeably". But, again, perhaps I'm just thinking in English.

What do you both say?

[flagarde]

For me Listage sounds very weird and really looks as a englicism and even carry some pejorative tone but maybe is just my fealing about it. Anyway even the definition the Academie is giving for such word is not describing what we want.

For the Code word I think the problem is that for a french speaker it seems to miss some word describing the code. Code is (I tried to find one but was unable to find one) never alone :

code secret
code d'honneur
code vestimentaire 
....

the only situations I was able to find with code alone looks just a short-cut for 1. password and 2. source code and seem to be not appropriated in writting.

For me :

 "comme on peut voir dans le code source 1"
 "comme on peut voir dans les code source 2 et 4"

looks ok, others alternatives i can think of are : "Source" and "série d'instructions" or "Programme" "série d'instructions" has the advantage that série is a not so bad synonym of "liste" wich is close to the Listing word and can carry the notion of order (cannot be mixed) while at least for me the liste doesn't carry in french or is less evident

liste de course
liste de noms
etc...

and instruction can be related to some rules, codes you need to follow, that for me represent quite well what a program or "Listing" is : some rules you have to follow in order.

The only draw back I can see is that it maybe carry a more low level (CPU level) meaning in computing science. I think french speaker will be more tented to say Programme for high level code and "série d'instructions" for low level.

Programme can carry a meaning of listing and is not only related to computers.

[gusbrs]

Hi @flagarde , this is a tricky one indeed. I suspect that not even in English the word is that good, as a lot of stuff can go into a listings environment, such that choosing a single word which is generic enough is a hard task, and whatever the result, it will be unsatisfying to some extent.

As to your suggestions, I think "Programme" is not general enough. A typical use case of listings/lstlistings is for code snippets. A "program" is comprised of a "series of instructions", but not any "series of instructions" make a "program". Regarding "série d'instructions", it sounds a little too heavy for the purpose. Reiterating the point I made earlier, it seems to work better to describe the "content of the environment", than to be a "good name to refer to the document element".

If "source" or "code source" work well in French, even in the plural, those seem reasonable alternatives, I think. I admit I still favor either "Listing" or "Listage", as they seem the least surprising here to me. But I'm not French...

And since this is a somewhat specialized/jargon term, ideally we should cater for its use in computer sciences literature, but we'd have to rely on someone acquainted with the subject.

Anyway, do you really think that "source" or "code source" is what "the median French-speaking LaTeX user would expect/want" for it, instead of "listing"/"listage"? (And consider this is a default value, which should be reasonable, and hopefully useful to most people, but it is also always configurable for anyone who wants something else.)

[flagarde]

hi @gusbrs

I can only talk for myself but Listage sounds ugly and a "des-englisism" and would refers for a french speaker to "the action of doing a list" and will have nothing to do with the "Listing". Using Listing has the advantage to stress that it is an englisism and so will warn it is maybe not what a french speaker would expect from the french word "Liste" which is represented by "Itemize" in LaTeX.

"source" or "code source" work well in French, I think even people with no computing background will have a naive idea of what will be the purpose of the text inside the document element you are refering to.

I think the best option would be to stay with "Listing" and ask more people if the other alternatives seam better for them

[gusbrs]

Hi, @flagarde . Ok, we leave it at "Listing" for the time being then. And thank you very much for your input in the discussion.

[gusbrs]

I had promised to leave this one open for a while, but I think it's been long enough now. Thanks again to all who contributed.