Discussion Projet:Correction syntaxique/Traduction

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons

Erreur #546, gestion des redirections de modèles[modifier le code]

Salut Ideawipik. J'ai vu que tu avais ajouté {{Patronymes}} à la liste des modèles catégorisant, et qu'il s'agit d'une redirection vers {{Patronymie}} qui est déjà dans la liste. Je peux essayer d'ajouter dans WPCleaner la gestion des redirections pour éviter d'avoir à saisir toutes les redirections dans la liste, mais j'aurais besoin d'une page qui me permet de vérifier que ça marche : est-ce que tu as un exemple ? --NicoV (discuter) 20 décembre 2019 à 12:51 (CET)[répondre]

Bonjour NicoV. La page d'homonymie qui m'avait permis de voir cette redirection peu utilisée est Szymanowski, catégorisée uniquement via ce modèle. (Les autres redirections vers Patronymie).
Pour info : J'en profite pour signaler un cas particulier. Le modèle {{Infobox Langue}} (pas dans la liste actuelle) catégorise par défaut mais pas s'il contient un paramètre nocat non vide (voir dernière ligne de la doc du modèle). C'est un comportement inverse à celui par exemple de Infobox Protéine/Caractéristiques espèces avec chromosome. Mais pas sûr que cela vaille la peine d'implémenter le premier cas dans la détection, la Catégorie:Inventaire de langues étant peut-être considérée comme "peu classifiante". Liste des rares "faux positifs" (4). Ces cas peuvent souvent être corrigés dans les articles en ajoutant une catégorie d'indication géographique. À suivre. Je te laisse voir. --Ideawipik (discuter) 20 décembre 2019 à 14:46 (CET)[répondre]
Édit : par contre je viens de me rendre compte que le paramètre typologie de {{Infobox Langue}} catégorise, lui.
Bonjour Ideawipik. Pour les redirections, je ne vais pas les gérer dans WPCleaner, car trop compliqué en analyse de dumps. Pour le reste, on va laisser tel quel pour l’instant. --NicoV (discuter) 22 décembre 2019 à 14:51 (CET)[répondre]

Liens vers les pages d'aide pour chaque erreur[modifier le code]

Bonjour NicoV. Même quand les pages d'aide spécifiques existent, un nombre important de liens vers ces pages ne sont pas fonctionnels, depuis WPCleaner, car non configurés. Penses-tu qu'il soit préférable

  1. de créer toutes les redirections P:CS/… ?
  2. de mettre directement les Projet:Correction_syntaxique/Erreur_syntaxique_… dans les paramètres error_NNN_link_frwiki de la configuration ?

Je préfère grandement la seconde option, notamment parce que les premières redirections sont dans l'espace principal. Mais, vu que tu as une vision plus globale, ton avis serait apprécié. — Ideawipik (discuter) 19 septembre 2021 à 01:11 (CEST)[répondre]

Salut Ideawipik. La configuration de ces liens dans WPCleaner sert surtout à faire des liens dans les résumés de modifications, donc une nette préférence pour que ce soit court. Si P:CS/xxx est gênant car dans l’espace principal, quelque chose comme Projet:CS/xxx serait nettement moins long que les liens en clair. --NicoV (discuter) 19 septembre 2021 à 22:24 (CEST)[répondre]
OK. Merci NicoV. Puisque les paramètres error_NNN_link_frwiki sont utilisés dans les commentaires de modifications, les redirections de ta proposition sont bien préférables. Initialement, j'avais en tête les liens du clic droit « Détail » sur les erreurs depuis l'interface graphique. Est-ce le même paramétrage ? Pour les résumés de modifications, il n'est pas nécessaire de placer des liens sur tous les types d'erreurs. Un lien vers le projet peut se révéler suffisant. — Ideawipik (discuter) 19 septembre 2021 à 23:00 (CEST)[répondre]
Salut Ideawipik. Oui, ça doit être le même paramétrage. Les liens sur les erreurs sont optionnels (par défaut, c'est désactivé), mais je ne sais pas trop qui l'utilise. --NicoV (discuter) 20 septembre 2021 à 07:44 (CEST)[répondre]

Remplacement error_564_replace_values avec le même nom de paramètre ?[modifier le code]

Bonjour NicoV. Dans la configuration de l'erreur 564, on a +Biblio|url-access|accès url pour le remplacement du nom de paramètre

Je voulais ajouter pour la traduction des valeurs +Biblio|accès url|free|accès url|libre. Cependant j'ai hésité avec +Biblio|url-access|free|accès url|libre et me suis demandé si les deux opérations/tests étaient systématiquement toutes deux appliquées et laquelle des deux opérations était réalisée en premier par WPCleaner. Si j'ai bien lu le code source, la réponse est affirmative et les remplacements error_564_replace_parameters sont appliqués avant les error_564_replace_values. Donc la première option semble la meilleure. Mais se pose alors une autre question, étant donné qu'on a pas encore de tel exemple, est-ce que le programme sait remplacer un paramètre par un autre du même nom ? Merci pour ta réponse. — Ideawipik (discuter) 12 mars 2022 à 18:46 (CET)[répondre]

Bonjour Ideawipik. Le remplacement ne peut marcher que si le paramètre est inconnu, car WPCleaner ne regarde les corrections que si il y a besoin, donc +Biblio|accès url|free|accès url|libre ne marchera pas. Il faudrait éventuellement une autre erreur pour les valeurs de paramètre inconnues, mais pas beaucoup de temps libre pour rajouter des choses. Pour l’ordre des corrections, je ne suis pas certain. --NicoV (discuter) 12 mars 2022 à 20:29 (CET)[répondre]
Merci NicoV pour la réponse. Dans ce cas (en attendant), on pourrait retirer la ligne +Biblio|url-access|accès url à error_564_replace_parameters et se contenter de modifier uniquement les paramètres "inconnus" dont la valeur est valide, car il est inutile de renommer un paramètre si sa valeur n'est pas valide. Ma proposition, conjointement à ce retrait serait:
  • d'ajouter dans error_564_replace_values
      +Biblio|url-access|free|accès url|libre
      +Biblio|url-access|gratuit|accès url|libre
      +Biblio|url-access|limited|accès url|limité
      +Biblio|url-access|registration|accès url|inscription
      +Biblio|url-access|subscription|accès url|payant
    
  • et pour les valeurs vides :
    • soit d'ajouter +Biblio||url-access à error_564_delete_values pour les retirer;
    • soit d'ajouter +Biblio|url-access||accès url| à error_564_replace_values pour les renommer vides (si cela fonctionne).
Qu'en penses-tu ? — Ideawipik (discuter) 12 mars 2022 à 21:17 (CET)[répondre]
Bonjour Ideawipik. Ok pour les modifications, plutôt la première option (supprimer ce paramètre si il est vide). --NicoV (discuter) 12 mars 2022 à 21:44 (CET)[répondre]
Bonjour Ideawipik. Pour finir, je me suis lancé dans l’erreur #572 pour détecter les paramètres avec des valeurs inconnues. La configuration est disponible sur Projet:Correction syntaxique/Traduction#Erreur 572. Une première analyse de dump est en cours de création sur Projet:Correction syntaxique/Analyse 572. Laisse-moi quelques jours pour faire une première passe sur les corrections automatiques que WPCleaner pourra faire. --NicoV (discuter) 13 mars 2022 à 12:25 (CET)[répondre]
Bonjour Ideawipik. C'était plus rapide que prévu : l'erreur est détectée et corrigée automatiquement pour certaines valeurs. Il reste environ 200 pages qui ont une valeur incorrecte non corrigée par le bot. --NicoV (discuter) 13 mars 2022 à 21:26 (CET)[répondre]
Merci NicoV. Super ! Je lancerai en fin de semaine un script pour convertir accès url en url si le paramètre a la forme d'une adresse internet et si le modèle ne contient pas de paramètre lire en ligne, url ou alias. Cela devrait bien réduire la liste puisque la confusion semble courante. Il faudra compléter la documentation des modèles et mettre en avant cela. — Ideawipik (discuter) 14 mars 2022 à 14:46 (CET)[répondre]