Skip to content

Contresens de traduction dans heapq.po #1628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
FrenchBear opened this issue May 10, 2021 · 10 comments · Fixed by #1629
Closed

Contresens de traduction dans heapq.po #1628

FrenchBear opened this issue May 10, 2021 · 10 comments · Fixed by #1629

Comments

@FrenchBear
Copy link

En lisant la doc de heapq de la bibliothèque, je pense qu'il y a un contresens de traduction en français (ligne 75 de heapq.po):
Ces deux points permettent d'aborder le tas comme une liste Python standard sans surprise : heap[0] est le plus petit élément tandis que heap.sort() ne modifie pas le tas !
Texte original en anglais:
These two make it possible to view the heap as a regular Python list without surprises: heap[0] is the smallest item, and heap.sort() maintains the heap invariant!

La traduction consière l'anglais 'invariant' comme un adjectif, alors qu'il doit être compris comme un nom. Plus simplement dit, heap.sort() conserve l'invariant de la liste (à savoir, heap[0] est le plus petit élément et heap[k]<=heap[2k+1] et heap[k]<=heap[2k+2]), mais ne conserve pas la liste invariante, elle peut être modifiée par l'appel à sort().

Un simple exemple montre que heap.sort() peut modifier le tas:

import heapq
heap = [1,4,2,3]
heapq.heapify(heap)
heap
[1, 3, 2, 4]
heap.sort()
heap
[1, 2, 3, 4]

Je pense que la traduction correcte de la phrase pourrait être:
Ces deux points permettent d'aborder le tas comme une liste Python standard sans surprise : heap[0] est le plus petit élément tandis que heap.sort() conserve l'invariance du tas !

(l'expression "conservant l'invariance du tas" est utilisée plus bas dans la traduction).

@JulienPalard
Copy link
Member

Bien vu ! Que pense-tu de #1629 ? Si c'est bon pour toi tu peux commenter dessus et on merge.

@christopheNan
Copy link
Contributor

Il faudra rétroporter vers 2.7 et les anciennes versions 3 (toutes impactées).

@FrenchBear
Copy link
Author

Pour moi c'est bon, la modification proposée me semble correcte et répond tout à fait à mon problème.

PyDocTeur pushed a commit that referenced this issue May 26, 2021
Automerge of PR #1629 by @christopheNan
#1628

closes #1628 
Merci pour la remontée du contresens.
@christopheNan
Copy link
Contributor

Retroportage requis.

@christopheNan christopheNan reopened this May 27, 2021
JulienPalard added a commit that referenced this issue Jun 4, 2021
JulienPalard added a commit that referenced this issue Jun 4, 2021
JulienPalard added a commit that referenced this issue Jun 4, 2021
JulienPalard added a commit that referenced this issue Jun 4, 2021
JulienPalard added a commit that referenced this issue Jun 4, 2021
@JulienPalard
Copy link
Member

JulienPalard commented Jun 4, 2021

C'est tout rétroporté \o/

pomerge --from-files *.po */*.po
git switch 3.8
pomerge --to-files library/heapq.po ; powrap -m; git add -u; git commit -m "Backporting for #1628."
git push
git switch 3.7
pomerge --to-files library/heapq.po ; powrap -m; git add -u; git commit -m "Backporting for #1628."
git push
git switch 3.6
pomerge --to-files library/heapq.po ; powrap -m; git add -u; git commit -m "Backporting for #1628."
git push
git switch 3.5
pomerge --to-files library/heapq.po ; powrap -m; git add -u; git commit -m "Backporting for #1628."
git push
git switch 2.7
pomerge --to-files library/heapq.po ; powrap -m; git add -u; git commit -m "Backporting for #1628."
git push

(Si qq se demande pourquoi j'ai pas fait un for, c'est qu'avant chaque push je relisais :D)

@christopheNan
Copy link
Contributor

Et ça se botise en prenant en paramètres le commit à retroporter + la version cible ?

@JulienPalard
Copy link
Member

Clairement ! Si ça arrive plus d'une fois par an ça s'automatise :)

@christopheNan
Copy link
Contributor

Le cas d'usage pourrait être toutes les traductions, non ?

@JulienPalard
Copy link
Member

Tu veux dire un petit bot qui passe régulièrement :

FROM=3.9
TO="2.7 3.5 3.6 3.7 3.8"
git switch $FROM
pomerge --from-files *.po */*.po
for branch in $TO; do
    git switch $branch
    pomerge --to-files *.po */*.po --no-overwrite
    powrap -m
    git add -u
    git commit -m "Backporting from $FROM."
    git push
done

?

@christopheNan
Copy link
Contributor

Oui.
En fait, sur le modèle de cpython, je rajouterais un label « backport » pour les PR et pomerge ne prendrait que les fichiers de la PR, avec une vérification si pas de conflit.
Voire, si le rétro-portage est la règle, un label « no-backport ».

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants