French translation review — native-speaker read-through of all 26 lectures

[mmcky]

Bienvenue @Honaminto — and thank you for taking this on.

This repository holds a machine-generated first draft of the QuantEcon Python Programming lectures in French. It is not a finished edition, and it has not been read by a French speaker yet. That's what this issue is for.

There is no deadline. Work through it whenever you have time, at whatever pace suits you. One lecture a month is genuinely useful. This issue is the tracker — tick lectures off as you go.

What you're looking at

Source	lecture-python-programming (English)
Translated by	Claude Opus 4.8, one pass, no human edits
Terminology	a 364-term French glossary injected into every translation
Cost / scale	26 lectures, ~35 minutes, ~$10
Status	draft — assume nothing has been verified

The precedent that matters: when the Persian edition was reviewed, the native speaker found meaning-inverting mistranslations that looked perfectly fluent. A machine translation that reads well can still say the opposite of what the English says. Your reading is the only thing that catches that.

Where to read

The French site isn't published yet, so please read the lectures directly on GitHub — the checklist below links to each one. Prose, headings, maths and code all render acceptably there. MyST directives ({note}, {exercise}) show as plain code blocks — that's a rendering artefact of GitHub, not a translation problem, so please ignore it.

If you'd rather read the English side by side, the same file lives at lectures/<name>.md in the English repo.

How to submit feedback: one PR per lecture

You've been added to the Translation Team (French) with write access, so you can branch directly in this repo — no fork needed. (You'll have an email invitation to accept first.)

For each lecture:

1. Create a branch, e.g. review/numpy
2. Edit lectures/<name>.md directly — fix the French as you'd write it
3. Open a PR titled e.g. Review: numpy.md
4. Tick the lecture off in the checklist below

One PR per lecture, please — not one big PR. Smaller PRs are easier to discuss, and if we disagree about one lecture it doesn't hold up the other twenty-five.

If you'd rather comment than edit — a PR with notes, or just a comment on this issue — that's completely fine too. Don't let the mechanics get in the way of the feedback.

What's most valuable

In rough order:

1. Meaning errors. The translation says something the English does not. These are the ones that matter most and the ones only you can find.
2. Wrong technical terms. A term rendered in a way a French economist or programmer wouldn't recognise. In the Persian review, "verbose" had been translated as if it meant "talkative".
3. Terminology that should be consistent but isn't — the same English term rendered differently in different lectures.
4. Unnatural French. Grammatically correct but not how anyone would write it. Academic register, please — these are teaching materials.
5. Anything in the code that looks wrong. The code should not have been translated at all, but comments inside it were. The Persian review also caught a genuine code bug this way.

Please don't spend time on these

• Missing spaces before : ; ! ? — we know. French wants a non-breaking space there and the model doesn't produce one. It's fixed automatically (details), so please ignore spacing entirely.
• Anything wrong in the English. That's a source issue — raise it upstream instead, and it'll flow back here.
• translation: blocks in the file header. Machine bookkeeping — please leave them alone.

Terminology is worth more than a file fix

If a term is wrong, it's probably wrong in several lectures. Rather than fixing each one, tell us and we'll pin it in the glossary — then every future translation gets it right automatically, including lectures nobody has reviewed yet.

There are already 6 questions waiting for you in action-translation#78 — including one I'd especially value your view on: we propose Standard normal → Loi normale centrée réduite, which neither AI model produced. That's a correctness call, not a consistency one, and it needs an economist.

Answering those 6 improves all 26 lectures at once. It's the highest-leverage thing in this issue.

Lecture checklist

Tick as you go. Order follows the table of contents, but review in any order you like — python_by_example.md and numpy.md are good places to start if you want the most-read lectures first.

• intro.md
• about_py.md
• getting_started.md
• python_by_example.md
• functions.md
• python_essentials.md
• oop_intro.md
• names.md
• python_oop.md
• need_for_speed.md
• numpy.md
• matplotlib.md
• scipy.md
• numba.md
• jax_intro.md
• numpy_vs_numba_vs_jax.md
• autodiff.md
• pandas.md
• pandas_panel.md
• writing_good_code.md
• workspace.md
• python_advanced_features.md
• debugging.md
• sympy.md
• troubleshooting.md
• status.md

What we'll do with your feedback

Every suggestion gets read for a pattern, not just applied:

• A term that recurs → into the glossary, so it's fixed everywhere forever
• A systematic problem → into the tool itself (that's how the spacing fix happened)
• Something only a human could catch → written up, so we know what machine translation can't do here

We'll keep notes as we go and summarise what we learn in this issue. If the same class of correction keeps appearing, that's a tool problem and we should fix it at the source rather than make you catch it 26 times.

---

Merci beaucoup, Emile. Questions and disagreement are very welcome — if something in these instructions doesn't make sense, that's our problem to fix, not yours to work around.

🤖 Generated with Claude Code