But wow, wrapping algorithm changed! Please let me the time to review this before merging.

Haha. Haha. Fsck. My powrap no longer wraps like github's powrap.

We should have worked on AFPy/powrap#76 sooner...

This is very bad, it mean that constributors will randomly have the old or the new wrapping behavior, either via poedit or via powrap ☹

I bet not wrapping at all is not an option: proofreading in github would be made impossible?

Haha. Haha. Fsck. My powrap no longer wraps like github's powrap.

OK, I'm lacking context. What are the different relationships between powrap, msgcat, GitHub and Poedit?

What are the different relationships between powrap, msgcat, GitHub and Poedit?

• powrap is a small Python wrapper using msgcat to wrap po files.
• msgcat do use a library (from the gettext project) to wrap text.
• gettext IIRC use the same library from the gettext project to wrap text.

So if gettext changes, powrap changes, and gettext changes, which looks good at first glance.

But if half of the contributors do use an old version, and half do use a new version, which will happen for many years, we'll have "diff battles": user1 commits with an old wrapping, user2 edits the file and commits with a new wrapping, user3 edits and commits with an old wrapping ... leading to an unreadable git log (where true edits are hidden in a gigantic mess of rewrapping).

The relationship with github now: if we stop wrapping, I bet ... oh let me test.

a few minutes later

mandatory escalator music

OK, I pushed a version with --no-wrap (in this same PR), just click the files changed and try to review the PR, it's highly inconvenient: most paragraphs overflow the screen, forcing to scroll horizontally a lot to read them:

I see a single decent solution: Stop enforcing a common strict wrapping as it does no longer exists anyway (different poedit version will probably soon wrap differently), just enforce a mere "configure your editor to wrap around the 79th column". And for readability of the git log, enforce at PR proofreading time, manually, a rule like "in a commit, there should not be edits on line you have not modified", meaning "do not rewrap what you have not touched", or in other words "if you edit a single typo I want to see a single diff, not a whole file rewrapped".

Another solution would be to work on AFPy/powrap#76 so "powrap is the only true wrapping", but it's bad: it would force everyone to use powrap, even people that previously had a good wrapping (users of poedit), which is not nice for them (powrap was here so contributors not using poedit have the same wrapping as users using it, so in reality only a few users had to use powrap).

Maybe we can promote the use of powrap in a Git pre-commit hook so that it won't be a burden on people not using Poedit? That way, if powrap uses a consistent algorithm from polib, we should be fine.

It would work, yes. But powrap started as a tool to help 10% of contributors and if we go this way it'll end mandatory for everyone, feel strange, and it reminds me the quote:

A foolish consistency is the hobgoblin of little minds.

I'd prefer to be lax: as long as the wrapping is OKish, and the diff is readable, it's OK.

Also I prefer removing a step in the contribution path that adding one.

But there's a catch: if someone have a poedit configured to not preserve the existing wrapping (which is not the default fortunately), he can make a commit with many unwanted edits mixed with real edits, and it'll be a PITA to fix.

OTOH, setting up a pre-commit hook is a one-time thing. If Contributing.rst gives the command to do it, it shouldn't be too much of a burden among the other tasks (cloning cpython etc).

Yes, it's easy for us all, but for newcomers it mean many prerequisites (a shell, a venv, understanding where powrap gets installed, let alone trying this on Windows with users using a graphical git client and poedit).

Another idea: tweak PyDocTeur so that it runs powrap right before merging.

It was the initial motivation for creating PyDocTeur and we never get to this point, as if it was forgotten en route. The only drawback is that the commit get modified (commit signature are not important at all in this repo, but still they would be lost).

draft comment, Feel free to amend, complete…

Let's sum up if i understand right.

issue:
gettext changed the way it wraps po files. msgcat forwards this new wrap in our .po files, as it uses gettext library. powrap uses msgcat under the hood, and therefore wraps the same way msgcat does.
The change appears in this PR, with new wrapping from original version of the .po files.

proposed evolutions for python-docs-fr:

It was the initial motivation for creating PyDocTeur and we never get to this point, as if it was forgotten en route.

I see. I had always wondered what PyDocTeur was for given that our CI is not too long long enough to be an impediment to merging fast.

The only drawback is that the commit get modified (commit signature are not important at all in this repo, but still they would be lost).

I thought commit IDs were already changed due to squash-merging?

I thought commit IDs were already changed due to squash-merging?

That's right, but I don't know if, in the case there's a single fast-forward commit, github use it directly (keeping the signature) or not. But we don't really care :D

I don't think it does, given that by default the commit title has the PR number appended at the end (which means the commit message, and hence the hash, changes). At any rate, yes, I think it's safe to say nobody cares.

I'm trying to replace the powrap workflow with a simple one just checking that we don't have lines > 80 chars.

awk ftw!

library/__main__.po:124 line too long: # Minuscule car toujours dans la même énumération, ignorez l'avertissement que Poedit affiche à cause de la majuscule à « Python ».
library/ast.po:770 line too long: # Il faut développer un peu plus que l'original car le lecteur ne comprend pas forcément les termes « body » et « orelse ». La même considération s'applique à bien des descriptions par la suite.
library/functools.po:292 line too long: "Algorithmes_de_remplacement_des_lignes_de_cache#LRU_.28Least_Recently_Used.29>`_ "
whatsnew/3.10.po:1774 line too long: # L'utilisation du terme "zip" peut laisser croire que le contenu de clipboard après la copie est structuré, mais ce n'est pas le cas. Le clipboard est populé avec du texte non-structuré.
whatsnew/3.10.po:1808 line too long: # "Coloration" plutôt que "mise en évendence" ou "surlignage" pour rester cohérent avec library/idle.po
whatsnew/3.10.po:2089 line too long: # "objets shelf" plutôt que "objets shelves" pour être cohérent avec library/shelve.po
whatsnew/3.9.po:270 line too long: # J'ignore volontairement le "as well" qui pour bien être traduit serait "en plus des changements ci-haut", ce qui me semble trop lourd.
whatsnew/3.9.po:846 line too long: # Voir le ticket qui mentionne que "block" n'est pas utilisé dans le sens d'un flux bloquant mais plutot dans le sens d'une annulation de l'opération.

On merge ?

Je pense qu'on peut y aller, oui. Tant qu'il n'y a personne pour bosser sur powrap et PyDocTeur, autant ne pas bloquer les traducteurs quitte à avoir quelques diffs plus gros que la norme.

Hello @JulienPalard ! Désolé, mais ton titre de pull request me semble invalide par rapport à ce que je suis programmé d'accepter.
Merci de le corriger ou d'ajouter le label meta si c'est une PR spéciale. Un exemple de titre valide serait : « Traduction de dossier/fichier.po ».

@JulienPalard Je ne sais pas par quelle méthode tu préfères merger ce genre de PR (squash ou non), je te laisse faire.

Hello @JulienPalard ! Désolé, mais ton titre de pull request me semble invalide par rapport à ce que je suis programmé d'accepter.
Merci de le corriger ou d'ajouter le label meta si c'est une PR spéciale. Un exemple de titre valide serait : « Traduction de dossier/fichier.po ».

ON Y EST PRESQUE ! Un p'tit label automerge et je merge ça !