8000 Some fuzzy in library/pty.po by Catadanna · Pull Request #1193 · python/python-docs-fr · GitHub
[go: up one dir, main page]

Skip to content

Some fuzzy in library/pty.po #1193

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

Merged
merged 6 commits into from
May 18, 2020
Merged

Some fuzzy in library/pty.po #1193

merged 6 commits into from
May 18, 2020

Conversation

Catadanna
Copy link
Contributor

No description provided.

Co-Authored-By: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>
@deronnax deronnax linked an issue Mar 22, 2020 that may be closed by this pull request
@Catadanna
Copy link
Contributor Author

Toutes les traductions ont été faites.

Co-authored-by: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>
christopheNan
christopheNan previously approved these changes May 3, 2020
@deronnax
Copy link
Collaborator
deronnax commented May 3, 2020

Hello. Je vois qu'il y a un conflit de fusion avec le "master" (la 3.8). Catalina, si tu ne sais pas résoudre ce problème, je peux le faire.

@Catadanna
Copy link
Contributor Author

@deronnax : Oui STP. Je ne sais pas comment résoudre ça. Dis-moi aussi comment tu fais, il faut faire un reverse du dernière commit ?

@deronnax
Copy link
Collaborator
deronnax commented May 4, 2020

non. Il faut "juste" fusionner la branche 3.8 avec sa branche de travail ("library-pty" ici).

En ligne de commande :

  • déjà, avoir la branche 3.8 du dépot python-docs-fr original (pas de son fork)
    • pour ça, ajouter le dépot original à ses remote : git remote add git@github.com:python/python-docs-fr.git
    • télécharger les nouveautés de ce dépot avec git fetch upstream
  • se mettre sur sa branches si besoin : git checkout library-pty
  • intégrer les nouveautés de la copie locale 3.8 qu'on vient de mettre à jour : git merge upstream/3.8
  • là il y aura un conflit de merge : c'est normal. Utiliser un outil graphique pour résoudre les conflits, genre VS Code ou Github desktop
  • une fois les conflits résolus, faire un git add <le fichier> si git le demande
  • ensuite commiter le tout avec avec git merge --continue
  • si on y comprend rien et qu'on s'en sort pas avec les conflit de fusion, annuler le merge avec git merge --abort et venir dire ici qu'on y est pas arrivé ;)

@Catadanna
Copy link
Contributor Author

Si je comprends bien, il y a des editeurs spécifiques pour la résolution de conflicts, c'est bien ça? Je m'imagine qu'on ne peut pas utiliser un simple éditeur de code, comme Emacs.

@deronnax
Copy link
Collaborator
deronnax commented May 4, 2020

si bien sûr qu'on peut faire ça avec un éditeur de texte, mais il vaut mieux être habitué. Les outils qui proposent de faire ça graphiquement rendent la chose plus facile

@Catadanna
Copy link
Contributor Author

Bon j'ai fait avec emacs en respectant la syntaxe du fichier. Selon ma logique, ça doit marcher.

@deronnax
Copy link
Collaborator
deronnax commented May 4, 2020

Tu as oublié un marqueur de conflit ;)

@Catadanna
Copy link
Contributor Author
Catadanna commented May 4, 2020

Lequel, celui qui indique les dates des deux conflicts? En tout cas, Emacs m'a gâché les caractères spéciaux, ce n'est pas la meilleure solution d'éditeur pour résoudre les conflicts.

@Catadanna
Copy link
Contributor Author

Je viens de regarder de nouveau, jene vois pas de marqueur de conflict. Il y a que les traduction et un sorte d'en-tête. Pour les corrections je fais clic plus haut sur "Détails", généralement, pour voir les erreurs.

@deronnax
Copy link
Collaborator
deronnax commented May 4, 2020

il sont là les marqueurs de conflits :

<<<<<<< HEAD
"PO-Revision-Date: 2020-03-25 16:25+0100\n"
=======
"PO-Revision-Date: 2020-03-21 13:08+0100\n"
>>>>>>> upstream/3.8

les chevrons et les signes égal

@Catadanna
Copy link
Contributor Author
Catadanna commented May 4, 2020

Je ne vois pas ça dans le fichier. J'ai refait upstream de nouveau comme tu m'as indiqué plus haut. Il est où ce marqueur maintenant, dans Origin, dans Upstream? En tout cas, après avoir refait Upstream avec toutes les étapes je n'ai pas trouvé ces lignes, et puis même avant de faire ça, je ne les ai pas trouvé dans la branche locale library-pty.
Et puis, il n'y a pas de conflit, il a été résolu.

@deronnax
Copy link
Collaborator
deronnax commented May 4, 2020

En effet, ça n'est pas là. J'ai dû consulter un build qui n'était pas le dernier.
Il te reste une erreur de pospell par contre ;)
library/pty.po:76:pty

@Catadanna
Copy link
Contributor Author
Catadanna commented May 4, 2020

C'est Emacs qui a fait cette erreur, ça m'a gâché les diacritiques. Commité de nouveau, voyons ce que ça donne ...

@deronnax
Copy link
Collaborator
deronnax commented May 5, 2020

la CI est toujours rouge. Tant c'est rouge, on ne pourra pas merger ;)

@Catadanna
Copy link
Contributor Author

Oui, apparement il s'agit d'un espace insécable. Je suis en train de fouiller ... je crains que c'est toujours à cause d'Emacs.

@deronnax
Copy link
Collaborator
deronnax commented May 5, 2020

Alors, je ne sais pas comment tu as fait, mais l'encodage du fichier a été changé, de utf-8 vers latin-1, et ça a corrompu les caractères étendus (accents et espace spéciaux), et ça fait que nos outils (qui travaillent en utf-8), ne comprennent plus ces caractères et lèvent des erreurs.
Il faut que tu repasses ces fichiers en utf-8.

Je pense qu'une fois cette PR finie, tu ne devrais plus utiliser emacs ;). Pour éditer les catalogues de traduction, on utilise beaucoup POEdit ici, et il ne prend pas l'initiative de changer l'encodage du fichier. Et pour les opérations Git, Github Desktop si tu es sous MacOS ou Windows est excellent.
EDIT: en fait il y a même une version Linux

@Catadanna
Copy link
Contributor Author

Attends, j'utilise poedit généralement, comme indiqué dans la documentation, mais j'ai du changer d'éditeur (j'ai choisi Emacs) seulement pour faire le merge entre les deux versions. C'est à ce moment là que le problème ait surgi. Ca doit être le paramètrage par défaut en Emcacs car je n'ai pas modifié aucun encodage (surtout pas car je sais quels problèmes peuvent être engendrés par le changement d'éncodage de texte). La prochaine fois j'utiliserai un fichier texte et je paramètrerai l'encodage. Ou encore mieux, je te laisserai faire.

@deronnax
Copy link
Collaborator
deronnax commented May 5, 2020

Pour régler les conflits de merge, je te conseille vivement VSCode, il est incroyable. OK, vu qu'on sait que ces problèmes sont apparus au moment du merge (commit dont le nom est juste "0" si je ne me trompe pas), je vais refaire le merge et réécrire l'historique de ta branche à partir du merge.
Je le ferai ce soir.

@deronnax
Copy link
Collaborator
deronnax commented May 5, 2020

résolu

@deronnax deronnax requested a review from christopheNan May 6, 2020 08:28
Co-authored-by: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>
@deronnax deronnax requested a review from christopheNan May 8, 2020 18:20
@deronnax deronnax merged commit 606dfb4 into python:3.8 May 18, 2020
@deronnax
Copy link
Collaborator

C'est intégré. Merci @Catadanna

@christopheNan
Copy link
Contributor

Merci pour ton investissement. Les premières PR ne sont pas évidentes car tu fais face à de vieux ours qui ont leurs habitudes…

@deronnax
Copy link
Collaborator

🐻

@Catadanna
Copy link
Contributor Author

Merci pour ton investissement. Les premières PR ne sont pas évidentes car tu fais face à de vieux ours qui ont leurs habitudes…

J'en ai aucun doute ;-)

@christopheNan
Copy link
Contributor

Oui Mathieu, il y a des vieux ours et des bisounours.

@deronnax
Copy link
Collaborator

Il y a aussi le fait qu'il y a pas mal de travail (que l'on fait bénévolement, sur notre temps libre) et on ne peut pas faire trop de support sur ce qui ne relève pas de la traduction, typiquement Git, plus encore à distance (ça peut demander des heures).
Après, il y a une question qui peut découler logiquement : pourquoi imposer des outils de développeurs (Git, Github, le format .po) pour de la traduction ?
La réponse simple pourrait être : nous avons utilisé ce que nous avions déjà sous la main, que nous connaissions déjà, et qui en plus est proche de l'outil original.
Des outils pour le grand public existent (ex: Transifex), mais ils amènent d'autres problèmes (on peut pas parler au contributeurs, faire des retours, automatiser des vérifications sur leurs PRs).

On réfléchit à faciliter les choses, mais on risque de garder ce workflow un peu technique (aride ?) pour un moment.

@Catadanna
Copy link
Contributor Author

@deronnax: Tout à fait logique!

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 this pull request may close these issues.

Je travaille sur library/pty.po
3 participants
0