Consultation des souhaits de la communauté/Actualités

27 avril 2023 : suite des souhaits de 2022 et début de ceux de 2023

Chers participants de la consultation des souhaits de la communauté,

Nous voudrions vous remercier pour votre participation à la consultation 2023 des souhaits de la communauté. La consultation est un élément crucial dans notre priorisation du développement de nouvelles fonctionnalités et améliorations des projets Wikimedia pour tous.

Début du travail sur les souhaits 2023

Nous sommes heureux d’annoncer que l’équipe Technologies communautaires a identifié le souhait « afficher les catégories sur le site mobile pour tout le monde » comme travail prioritaire pour l’équipe dans les prochains mois après la fin du travail sur l’amélioration des diffs des scissions de paragraphe. C’est aussi le 18^e souhait de la consultation 2022. La faisabilité technique et l’impact potentiel sur l’expérience utilisateur du site mobile pour tous les utilisateurs ont guidé cette décision.

Nous comprenons l’importance de cette fonctionnalité pour la communauté, et sommes heureux de travailler dessus. Nous vous tiendrons au courant de notre progression, et nous vous fournirons bientôt un calendrier de mise en œuvre. Par ailleurs, nous avons commencé à rechercher comment diffuser l’outil « Qui a écrit ça ? » sur d’autres wikis, le 7^e souhait de la consultation 2023 ; nous espérons avoir bien progressé d’ici quelques mois. Nous prévoyons le déploiement de l’outil « Qui a écrit ça ? sur la Wikipédia en français dans les prochains jours, et dans d’autres langues dans les prochaines semaines.

Mode sombre

Nous voulons vous informer des actualités concernant le souhait d’un « mode sombre ». Nous sommes heureux de vous informer que l’équipe Web s’est emparé de ce souhait et va travailler assidument sur son développement. Cependant, en raison de contraintes techniques et de conception, l’équipe Web sortira la première version du « mode sombre » en bêta. Nous comprenons l’importance de l’accessibilité et de l’inclusivité, et nous nous engageons à nous assurer que cette fonctionnalité répond aux besoins de tous les utilisateurs. Par ailleurs, de nombreux modèles doivent être ajustés, et les bénévoles doivent être prévenus des modifications nécessaires avant la disponibilité complète du mode sombre. L’équipe Web va travailler sur la documentation de ces problèmes, nous vous remercions de votre patience. N’hésitez pas à vous inscrire à l’infolettre de l’équipe Web pour suivre les actualités de ce projet.

Je voudrais aussi prendre un moment pour remercier les bénévoles qui ont pris le temps de collaborer avec moi en toute confiance pendant mes fonctions ici, et annoncer mon départ prochain de mon poste de chef de produit de cette équipe de Wikimedia Foundation. Merci à ceux parmi vous qui ont pris le temps de participer aux propositions, à la résolution de problème avec nous, et à ceux qui se sont attaqués bénévolement à la résolution technique de certains souhaits — je garderai en mémoire ce souffle inspirant durant toute ma carrière.

En mon absence, un trio absorbera mes responsabilités : vous pourrez faire appel, après mon départ, au trio composé de KSiebert (WMF) (direction des services techniques), DMaza (WMF) (responsabilités techniques) et JSengupta-WMF (responsable conception). Vous pourrez communiquer avec l’équipe comme auparavant ; les pages de discussions des projets, actualités et de l’équipe sont les lieux les plus appropriés pour joindre l’équipe. Nous voudrions collectivement vous remercier une fois encore pour votre participation à la consultation des souhaits de la communauté. Votre participation nous aide à prioriser et améliorer les projets Wikimedia, et nous espérons vous voir continuer cet engagement.

Bien à vous,

NRodriguez (WMF) et le reste de l’équipe Technologies communautaires

13 mars 2023 : actualité concernant la meilleure gestion des scissions de paragraphe dans les diffs

The team has continued work on this wish on both the engineering and design side and we wanted to share the updates with you.

Thank you to all of you who took the time to engage with us and provide feedback on the talk page. We read through all of the feedback and did an aggregate analysis on the points made. We then combined your feedback on those proposed designs, as well as unmoderated user research, and we've finalized the proposed designs to go into engineering for the improvements regarding the wish changes.

Please see the designs in this update which include:

• Switching between diff modes via dropdown
• Improving the accessibility of inline diffs with legends and tooltips for desktop
• Improving the display of a change that introduced a new line or paragraph
• Improving the display of a change that deleted an existing line or paragraph

In addition, a demo of the changes for the underlying comparison engine has been created.

Before you try out the demo to give us feedback, please note:

• It's a work in progress, our QA engineers are currently using a list of comprehensive diffs to make sure the changes are consistent with the current version of the two-column diff experience or an improvement on the UI.
• The demo page does NOT include all final UI changes but can give testers a good sense of how the completed two-column diff experience will end up looking.
• To use the demo, paste the same text into the two boxes and modify the text in the right box. The diff under it will show what changed.

We'd love to hear your feedback on our talk page!

Next Steps

• Accessibility of Design Colors: Our designer is working closely with our Design Systems team to determine the accessibility of the designs. We anticipate having to change the shade of them to a slight degree to make it more accessible but the colors will remain similar to the blue and yellow currently displayed on two-column and inline diffs.

• Release plan: We are working out a release plan and a timeline of next steps and will be including this in our next project updates! Releasing changes to the underlying engine on the diff follows a different process than traditional releases in Mediawiki software so we will be sure to update you with steps and details next time.

We also want to include big thank you in this update to a non-Community Tech staff member, Tim Starling, who graciously stepped up to help us with the underlying changes in the C++ engine of wikidiff2. We are always happy to receive support fulfilling wishes from other members at the Foundation that have the expertise necessary to fulfill a wish even if they are not in the Community Tech team.

We're looking forward to hearing from all of you!

Open Questions from first update: We want to hear from you!

• Are you interested in conducing user research on the new proposed interface to diff paragraph splits? If so, will you please post that you're interested in the Talk Page?
• What other pain points manifest themselves when you view the diff?
• How might we address the root pain points that address the confusion around paragraph splits?
• How does the use of color indicate which content is added, removed, or stayed the same?

7 mars 2023 : Publication des résultats de la consultation 2023 des souhaits de la communauté

L’édition 2023 de la consultation des souhaits de la communauté s’est achevée. Nous avons publié les résultats de la consultation et allons fournir une note pour présenter les suites prévues en avril 2023.

20 décembre 2022 : Mise à jour du Souhaithon

Cette année, L’équipe Technologies communautaires reprend la tradition de consultation interne à WikiMedia Fondation : le (Souhaithon). Pendant cette consultation, notre équipe annule les réunions pendant une semaine entière et passe l'intégralité de son temps à travailler sur des souhaits "plus modestes" en dehors de notre charge de travail habituelle sur les souhaits "plus grands". Par exemple, une (meilleure visualisation des différences (de versions) dans les sauts de paragraphes) est une demande complexe qui nécessite une planification importante en termes de recherche de conception, d'architecture technique ainsi que sur les plans d'assurance qualité et les dépendances avec l'équipe "Performance". Ces souhaits prennent généralement des mois pour leur réalisation. Le Souhaithon nous incite à exaucer des demandes plus simples et nécessitant moins de dépendances et de planification entre équipes. Bien qu'elles ne soient pas les plus partagées, nous pensons toujours qu'elles sont de grande utilité, en particulier pour ceux qui ont voté pour.

En décembre dernier, nous avons lancé une invitation à participer à d'autres ingénieurs, concepteurs et gestionnaires de différentes équipes pour nous rejoindre pendant une semaine Souhaithon et nous aider à progresser sur le travail requis pour exaucer ces petits souhaits. Grâce à la participation supplémentaire d'ingénieurs d'autres équipes, nous avons pu réaliser quatre souhaits et réécrire une portion de code important. Veuillez noter que dans l'esprit d'agir rapidement et de concrétiser des besoins, nous n'avons pas mené le cycle complet de recherche et de communication que nous effectuons habituellement sur des demandes plus importantes. Vous pouvez en savoir plus sur les réalisations de la semaine dernière, leur impact et leurs sorties prévues ci-dessous.

Souhait : Suggestion automatique de lien vers un élément Wikidata après création d'un article

Cette demande a reçu 92 suffrages et est arrivée 12e dans la consultation (souhaits 2022).

Problème : Quelqu'un crée un article dans Wikipédia en langue A, mais il ne sait pas qu'il existe déjà le même article dans Wikipédia en langue B (souvent un WP moins expérimenté), donc aucun lien Wikidata n'est fait. Le proposant a vu de nombreux cas entre WP chinois (zh) et WP cantonais (yue).

Le travail est terminé et sera disponible sous forme d'outil la semaine du 16 janvier 2023.

• Souhait original
• Tickets pertinents / Référentiel / Correctifs
  • ✅ T308 059
  • ✅ Code sur gitlab
    • Ajouter une vérification pour voir si l'article a des liens annexes associés
    • Mettre en œuvre les changements en fonction des retours
    • Ajouter ESLint et corriger les erreurs de code
    • Définir le serveur de nœuds
    • Ajouter une fenêtre contextuelle OOUI et supprimer les balises html
    • Ajouter un bouton d'aide à la boîte de dialogue contextuelle
• Page de documentation (brouillon): AutosuggestSitelink
• 🏆 Remerciements particuliers aux membres de l'équipe : Harumi Monroy, Julieta Fernandez (Design), MusikAnimal, Sam Wilson, David Martin, Natalia Rodriguez
• Statut: Le travail a été fusionné et est disponible pour des tests en version bêta, et sera déployé auprès des utilisateurs avec la première livraison de 2023 qui est prévu pour la semaine du 28 janvier.

Impact du souhait

• Plus de pages Wikipédia (et d'autres projets) liées aux éléments Wikidata correspondants
• Meilleure connaissance de Wikidata pour les contributeurs wiki
• Meilleure maintenance des liens entre les langues de Wikipédia et autres avantages de Wikidata

Souhait : Autoriser la négation pour les filtres de balises

Cette demande a reçu 41 suffrages et est arrivée 27e dans la consultation (souhaits 2022).

Problème: Lorsque vous affichez des flux tels que Special:Contributions ou Special:RecentChanges, nous pouvons actuellement filtrer par balises, mais pas par négation de balises.

Le travail est terminé et sera disponible dans le déploiement de la semaine du 3 janvier 2023.

• Souhait original
• Tickets pertinents et correctifs
  • ✅ Tâche T119 072 réalisée : Autoriser la négation de balise sur Special:Contribution
  • ✅ Tâche T174 349 réalisée : Autoriser la négation de balise sur Recent Changes
  • ✅ Patch fusionné 866 814: test d'utilisabilité ("expérience utilisateur") pour la négation de balises sur Special:Contribution
  • ✅ Patch fusionné 867 726: test corrigé pour que les formulaires fonctionnent mieux avec hide-if (pour autoriser ensuite)
  • ✅ Patch fusionné 866 817: test d'utilisabilité ("expérience utilisateur") pour la négation de balises sur Special:Log (hors demande, mais facile)
  • ✅ Patch fusionné 867 255: afficher la négation de balise dans l'API et le flux (pour autoriser ensuite)
  • ✅ Patch fusionné 867 731: empêcher tagfilter d'être défini sur 'tout' (pour autoriser ensuite)
  • ✅ Patch fusionné 867 224: test d'utilisabilité ("expérience utilisateur") pour la négation de balises sur Recent Changes / Watchlist
• État :
  • 866 814 déjà en fonction (càd pour Special:Contributions)
  • 6 patchs fusionnés, deux tâches fermées, un souhait exaucé
• Étapes suivantes :
  • Déploiement pour 'Modifications récentes' et 'Spécial:Journal' dans la prochaine fournée
• 🏆 Remerciements particuliers aux membres de l'équipe: Roan Kattouw, Denny Vrandecic, James Forrester, Moriel Schottlender

Mention d'honneur à Matěj Suchánek, un bénévole qui a jeté les bases de ce en écrivant ce patch en 2020.

Impact du souhait

Les utilisateurs pourront filtrer les modifications en fonction d'une balise sur les 'Modifications récentes', la 'Liste de suivi', 'Spécial:Contributions' et 'Spécial:Journal'

Souhait: Activer le 'bouton de remerciement' par défaut dans la 'Liste de suivi' et les 'Modifications récentes'

Cette demande a reçu 62 suffrages et est arrivée 33e dans la consultation (souhaits 2022).

Problem: The Thanks button is only available on individual Page Histories, which very few people interact with on a regular basis -- especially more experienced editors. The number of newbies looking at individual history pages, is miniscule.

• Souhait original
• Tickets pertinents et correctifs
  • ✅ T51 541
  • ✅ T90 404
• 🏆 Special thanks to Team Members: Jon Robson
• Status: The work has been merged and is available for testing in Beta, and will be deployed to users with the first train of 2023 which is scheduled for the week of Jan 3.

Impact of wish

Les utilisateurs pourront désormais remercier d'autres utilisateurs à partir des pages 'Liste de suivi' et 'Modifications récentes'.

Wish: The "tag name" on the change line should link directly to "tagged changes"

This wish received 18 support votes and ranked as the #162 most popular wish in the list of the 2022 wishes.

Problem: The tag on the change line currently looks like this:

   14:33 John Callahan's Quads!‎ (diff | hist) .. (−12) .. Rng0286 (talk | contribs) (lorem ipsum) (Tags: Visual edit, Mobile web edit)

The tag name is either a link to a help page or just plain text. It is not easy to find edits with the same tag.

• Souhait original
• Tickets pertinents et correctifs
  • ✅ T301 063
• 🏆 Special thanks to Team Member: James Forrester
• Status: The work was reverted on Jan 11.

Impact of wish

Users will now be able to click on the tag name to find edits with the same tags within change lines.

Refactoring code from the Page Triage codebase for easier collaboration

• Souhait original
  • ✅ 13 Refactoring Patches
• 🏆 Special thanks to Team Members: Kosta Harlan, Sammy Tarling (TheresNoTime), Jason Sherman, Gergo Tisza
• Status: The work has been merged

Impact of work

Modernizing the codebase to help make bug fixing and feature development easier

What's Next?

In addition to the wishes granted above, we were able to make some progress on a handful of other wishes. Community Tech will be assessing which wishes we can finish based on the progress left on them. We are excited to continue this Wishathon tradition and welcome your feedback in the talk page of this update! Thank you for participating in the Wishlist, we hope to see you in the upcoming annual survey opening January 23, 2023.

December 16, 2022: Realtime Preview is coming out of beta

The Realtime Preview for Wikitext is coming out of beta as an enabled feature for every user of the 2010 Wikitext editor in the week of January 9, 2023. It will be available to use via the toolbar in the 2010 Wikitext editor. The feature was the 4th most popular wish of the Community Wishlist Survey 2021.

December 5, 2022: The 2023 Community Wishlist Survey will happen in January

Do you have an idea for a tool or platform improvement for Wikimedia projects? This announcement is for you!

The Community Wishlist Survey (CWS) 2023, which allows contributors to propose and vote for tools and improvements, starts next month on Monday, 23 January 2023, at 18:00 UTC and will continue annually.

We are inviting you to share your ideas for technical improvements to our tools and platforms. Long experience in editing or technical skills is not required. If you have ever used our software and thought of an idea to improve it, this is the place to come share those ideas!

The dates for the phases of the survey will be as follows:

• Phase 1: Submit, discuss, and revise proposals: Monday, 23 January 2023, to Monday, 6 February 2023
• Phase 2: WMF/Community Tech reviews and organises proposals: Monday, 30 January 2023 to Friday, 10 February 2023
• Phase 3: Vote on proposals: Friday, 10 February 2023 to Friday, 24 February 2023
• Phase 4: Results posted: Tuesday, 28 February 2023

If you want to start writing out your ideas ahead of the Survey, you can start thinking about your proposals and draft them in the CWS sandbox.

We are grateful to all who participated last year. See you in January 2023!

December 1, 2022: Better diffs usability testing

We have been working on different design alternatives for Better diff handling for paragraph splits, the #1 wish in the Community Wishlist Survey 2022! We have invited the community to sign up for usability tests and give feedback.

May 3, 2022: Real Time Preview launching to partner projects

We have launched a version of the Realtime preview feature to Polish Wikipedia. Its community has agreed to partner with us and give us feedback on how to improve it before we launch to the rest of the users. Please find our complete Release Plan. En savoir plus

This feature touches one of the most used editors (Wikitext 2010) across wiki projects. We've thus decided to roll it out as a Beta Feature before we release the feature to everyone. This will allow us to collect feedback and make improvements before we release to everyone.

We are partnering with users early on to understand behavior on the new tool and make improvements. Depending on the user’s connection, we are aiming to observe and evaluate patterns regarding the automatic and manual reloads of the preview pane, as follows:

• Automatic reload: Debounce time. When the preview pane is automatically reloading, is our debounce time sufficient to provide a fluid experience?
• Automatic reload: Discoverability of the manual reload button. When the preview pane is automatically reloading, is the manual reload button that appears while hovering over the preview pane easy to find?

and/or

• Manual reload: Discoverability/Display time of the manual reload status bar.

When the preview pane is NOT reloading automatically, the user will see a status bar inviting them to manually reload. Is the discoverability of the bar sufficient? Is the status bar obstructive to the users’ workflows?

We will aim to observe both of these scenarios for users with stable high-speed internet connections. In both cases, we will be performing the test on two pages: one short article without images (for faster reload time) and another one with a large content and multimedia assets (for slower reload time).

Aside from our main investigation, we will also be observing the following during our screen-sharing sessions with users:

• Discoverability of the overall feature: although users will be notified of the existence of the realtime preview feature, and the potential relationship between the latter and the "Show preview" feature.
• User screen sizes- This data could be helpful to understand how useful the Realtime Preview is for folks with a smaller screen. Does this make their experience too crowded?
• Usage of syntax highlighting/Code Mirror
• Understanding that both panes do not have a synced scrolling behavior.

If you would like to give us any feedback on any of the open questions above, please reach out to us in the talk page as we are eager to hear about the usability of this new feature. Thanks for building with us!

Résultats 2022

L'enquête sur les vœux 2022 de la communauté est terminée ! Nous tenons à remercier tous ceux qui ont participé à l'édition de cette année et à exprimer notre gratitude toute spéciale à ceux qui ont apporté des contributions exceptionnelles à l'enquête sous les résultats. Nous n'aurions pas pu le faire sans vous tous !

Vous êtes curieux de savoir ce qui se passera ensuite ? Découvrez notre processus de priorisation et consultez le classement des propositions priorisées pour cette année. En savoir plus

8 novembre 2021 : Avertir lors de l’ajout d’un lien vers une page d’homonymie

We have an update about the wish. We have finished user tests. En savoir plus

Hello everyone,

Many thanks for your great support and feedback on the proposed user experience and designs for this wish. This update is regarding the usability testing, which was conducted in parallel with community members on the talk page, as well as the first “Talk to Us hours” video call last September. Thanks again for your valuable inputs!

The goal of this round of usability tests was to determine if our proposed designs were successful in warning users about the potential risks of adding a link to disambiguated page in the 2010 wikitext editor without inhibiting users from continuing to edit. We conducted the test on usertesting.com with 5 editors total.

Here are the insights we gathered from the tests:

• 2/3 of users successfully noticed the new notification warning them about the disambiguation link they added. Two users were not able to see the notifications due to complications with the testing interface and instructions.
• All users who saw the notification found it helpful and easy to understand. When users noticed the disambiguation notification and understood its purpose, most of them stated that it was useful without being disruptive to their edit flow.

Acknowledgments: This test was conducted on beta-wiki with a limited content pages. Before we could push some recent user experience and engineering improvements for this wish, including the new link selector widget for the Wikitext editor. We are hoping that these changes will mitigate some of the difficulties encountered by the users during this usability test.

Not all of these editors from this panel are experienced users. Although this wish is intended to be helpful for every user – we assume that less experienced editors will tend to use the VisualEditor over the wikitext editor, thus making this new feature less relevant for them.

We are grateful for your feedback on this talk page and the Talk to Us for our team to get a better understanding of your needs as experienced contributors. Thanks so much for your feedback on the talk page!

2 novembre 2021 : Prévisualisation en temps réel du wikicode

Merci pour vos commentaires sur la page de discussion et pendant la dernière visioconférence « Discutez avec nous ». Par ailleurs, nous avons mené des tests de facilité d’emploi, dont nous présentons les principales trouvailles. En savoir plus Bonjour à tous,

Merci sincèrement pour votre soutien et vos retours massifs sur les designs proposés. Merci pour vos messages sur la page de discussion et pendant la dernière visioconférence « Discutez avec nous ». Nous avons beaucoup appris sur la manière dont les utilisateurs expérimentés contribuent.

Par ailleurs, nous avons mené des tests de facilité d’utilisation sur la plateforme usertesting.com, auxquels 5 contributeurs ont pris part. Vous trouverez ci-dessous certaines des trouvailles et intuitions dégagées :

• La moitié des utilisateurs ont trouvé le nouveau bouton « Prévisualiser » dans la barre d’outil. Une des raisons à cela peut avoir pour origine les modèle comportementaux développés à partir du bouton « Prévisualiser » existant en bas de la boite de l’éditeur. Nous allons concevoir un point clignotant peu dérangeant avec un guide surgissant. Nous espérons que cela permettra de remarquer plus facilement cette nouvelle fonctionnalité.
• All users found the existing "show preview" button.
• All users understood the difference between both buttons. One could be used while editing (offering a quick glimpse at the output). The other could be more helpful for proofreading before publishing the changes.
• One user reported that it might always be easy to understand the relationship between the Wikitext input and the preview output. To mitigate this, we are exploring ways to highlight the text in both panes and align the scrolling or editing behavior.

Acknowledgments:

• Not all of these editors are experienced users. Although this wish is intended to be helpful for every user – we assume that less experienced editors will tend to use the Visual Editor over the wikitext editor. This will make the new feature less relevant for them.
• We are also working on improving the scaling of both panes. We want to allow for optimal support to both small and ultra-wide displays alike.

Again, thanks so much for your feedback!

19 octobre 2021 : rejet du souhait de robot bibliographique

Titre du souhait : Robot bibliographique

Tâche Phabricator d’investigation

Classement du souhait : 14^e

Résumé du motif : trop grande portée, pas assez de votes.

Nous avons décidé de rejeter ce projet, après un examen attentif et de nombreuses phases de commentaires au sein de l’équipe et conversations avec d’autres équipes chez Wikimedia et les affiliés.

Jusitification : Tout d’abord, les ingénieurs et designeurs ont examiné la portée du travail défini dans la présentation du problème du souhait. Nous avons déterminé que le travail nécessaire dépassait grandement nos premières estimations.

Ce souhait a obtenu une mauvaise note dans notre processus de priorisation parce qu’au premier coup d’œil, il a semblé difficile de dupliquer le comportement de Citoid dans Wikidata. Nous avions considéré que cela avait une faible complexité technique et de conception parce que nous pouvions réutiliser le code et le design. Cependant, les références dans Wikidata doivent être liées comme des références aux autres objets de la base de données, ce qui augmente significativement la complexité.

Ce souhait n’a pas atteint le score des 10 souhaits les plus populaires. Il est arrivé en position 14. Nous nous sommes trompés dans nos estimations initiales. En fait, l’équipe Wikidata de Wikimedia Allemagne a travaillé sur ce souhait pendant plusieurs mois. La solution finale était trop complexe pour la mettre en place au vu des ressources disponibles à ce moment-là. Cela aurait pris plusieurs mois à l’équipe Technologies communautaires pour l’achever, et nous voulions travailler sur d’autres souhaits plus populaires.

4 septembre 2021 : Prévisualisation en temps réel du wikicode

We have made progress working on the Real Time Preview for Wikitext tool. We have two questions about its design. We invite you to answer on the project talk page. En savoir plus

Thank you for your feedback

Hello all, we are back with an update on the proposed designs for this wish. Thanks for all of your comments on the talk page. We heard what you said and synthesized the feedback as follows:

• The button to preview the wikitext output should be more intuitive, the person clicking it should know what it does.
• The button to preview the text should be in the toolbar.

We then took a second try at creating the following set of designs. We are proposing a new button appears in the toolbar:

We are proposing than when user previews the content, the preview button label remains "blue" to indicate that the preview state is on, and activated:

The preview button would turn back to black if users toggle it off and the preview would disappear.

Horizontal vs Vertical

Please note that these proposed designs are illustrative. We only included a vertical version because we are currently investigating if the ability to have a wide screen will still be an option given the planned and upcoming work on Web desktop improvements which would limit the page to 960px in width, making it too cluttered to have a horizontal view.

Open Questions: We want to hear from you!

• Does the new button placement seem more intuitive to the workflows in the toolbar?
• Does the current proposed layout feel like there is enough space to view both the wikitext and the output?

Thanks so much for your continued feedback on the talk page!

27 août 2021 : Prévisualisation en temps réel du wikicode

We are making initial steps on the Real Time Preview for Wikitext tool. We have questions about its design. We invite you to answer on the project talk page. En savoir plus

Proposed Designs

Horizontal Desktop Layout

A new button will appear. This gives editors the option to preview the text on the side in real-time:

Note: The pink box above is just to draw attention to the button, it will not actually appear to users.

Editors will be able to click on the button highlighted above. If they do that, the following layout would allow them to preview the output in a scrollable fixed container:

Vertical Desktop Layout

The following new user interface element will appear when a user has a vertical desktop screen:

Note: The pink box above is just to draw attention to the button, it will not actually appear to users.

Editors will be able to click on the button highlighted above. If they do that, the following layout would allow them to preview the output in a scrollable fixed container:

The engineers have begun work on these changes. We are introducing the changes inside of MediaWiki core. We'd love to hear your thoughts on our proposed designs. We'd especially love feedback on:

• Making the copy and button placements intuitive
• The overall feel of the proposed designs

We're looking forward to hearing your thoughts on our proposed designs and any other considerations!

Open Questions: We want to hear from you!

The solutions above are proposed and in early stages. We'd love to hear your feedback on the talk page. Your insight can help us understand other approaches, risks, and solutions.

These are our questions to you:

• How do you think this will influence the way you edit?
• Does the icon on the expand button prepare the editors to understand what it does? Is it distrupting?

20 août 2021: La Consultation 2022 des souhaits de la communauté se fera en janvier

Bonjour à tous,

Nous espérons que vous vous portez au mieux malgré ces temps d'épreuve ! Nous voudrions partager quelques informations sur un changement dans la Consultation 2022 des souhaits de la communauté et serions heureux de recevoir vos commentaires sur ce sujet.

L’édition 2022 de la consultation des souhaits de la communauté aura lieu en janvier 2022. Nous avons besoins de plus de temps pour travailler sur les souhaits de 2021. Il nous faut également du temps pour préparer quelques changements pour les souhaits de 2022. En attendant, vous pouvez utiliser un bac à sable dédié pour déposer vos premières idées de souhaits pour 2022.

La proposition des souhaits et leur réalisation se feront la même année

Par le passé, l’équipe Technologies communautaires lançait la consultation des souhaits de la communauté en novembre pour l’année suivante. Par exemple, les souhaits pour 2021 ont été déterminés en novembre 2020. Ceci fonctionnait bien il y a quelques années. En ce temps là, nous avions l’habitude de commencer à travailler sur les souhaits juste après la publication des résultats du vote.

Néanmoins en 2021, il y a eu un décalage entre le vote et le moment où nous avons pu commencer à travailler sur les nouveaux souhaits. Jusqu’à juillet 2021, nous avons travaillé sur les souhaits pour 2020.

Nous espérons que d'avoir la liste pour l'année 2022 en janvier 2022 sera plus intuitif. Ceci nous donnera aussi du temps pour compléter davantage de sujets restants des souhaits de 2021.

Encourager une participation plus large des communautés exclues historiquement

Nous pensons à la façon de rendre la liste des souhaits plus accessible à ceux qui veulent participer. Nous voudrions prendre en charge davantage de traductions, et encourager les communautés qui ont moins de ressources à être plus actives. Nous souhaiterions avoir plus de temps pour faire ces changements.

Un nouvel espace pour discuter avec nous des priorités et des souhaits qui n'ont pas encore été statués

Nous aurons laissé passer 365 jours sans nouveaux souhaits. Nous vous encourageons à prendre contact avec nous et souhaitons vous retrouver sur la page de discussion, mais également à nos rendez-vous Talk to Us (« Parlez-nous ! ») bi-mensuels ! Ils auront lieu à deux heures différentes, pour convenir aux fuseaux horaires du globe.

Nous commençons notre premier rendez-vous le 15 septembre à 23 h 00 UTC. Les détails concernant l’agenda et le programme vous seront donnés bientôt !

Remue-méninges et rédaction des propositions avant la phase de proposition

Si vous avez déjà vos premières idées de souhaits, vous pouvez utiliser le nouveau bac à sable de la consultation des souhaits de la communauté. De cette manière, vous ne les oublierez pas avant janvier 2022. Vous pourrez y revenir pour les préciser. Mais rappelez-vous que les modifications faites dans le bac à sable ne comptent pas dans la consultation !

Vos commentaires

• Que devrions-nous faire pour améliorer les pages de la consultation ?
• Comment voudriez-vous utiliser notre nouveau bac à sable ?
• Quels seraient les risques d'après vous au fait que nous changions la date de la consultation 2022 ?
• Qu’est-ce qui permettrait à davantage de personnes de participer à la consultation 2022 ?

Vous pouvez répondre sur la page de discussion (dans la langue de votre choix) ou lors de nos rendez-vous Talk to Us.

18 août 2021 : Avertir lors de l’ajout d’un lien vers une page d’homonymie

We have moved forward with the design. We would like you to answer our questions. En savoir plus

Progress with the design

Hello everyone, and thanks to those of you who have been active on our talk page and tested the proof of concept script for displaying a warning. We have moved forward with designing for the last two requirements in our proposed solutions and wanted to share them with you so that we could hear your input!

As an Editor using the link toolbar to search for knowledge to reference in my article, I can:

• See a warning before publishing if I have introduced a disambiguation link in my article
• Visibly differentiate disambiguation links as a different type of content than articles that come up on my suggestions

For the first solution above, we are proposing displaying this yellow box warning when wikitext users add a link:

For the second solution above, we are proposing changing the copy to better describe what a disambiguation page means in the wikitext link button and in the visual editor link pop-up:

Open questions

We'd love to hear your thoughts on our proposed designs. We'd especially love feedback on:

• Making the copy accessible and making it easier to glean what a disambiguation page is
• Making sure the warning for wikitext editors feels preventative without coming off as discouraging-- editors should still be able to publish even if they have introduced faulty links

We're looking forward to hearing your thoughts on our proposed designs!

5 août 2021 : supprimer/restaurer la page de discussion associée

We have completed our first investigation. You can track this inside this ticket on Phabricator. The bulk of the work here will be around security and performance considerations. We estimate tackling this work within the coming months. En savoir plus

2 août 2021 : Avertir lors de l’ajout d’un lien vers une page d’homonymie

We have completed our first part of the wish. As a result, we will release a new change in a few days. Thank you for all the comments you have given. En savoir plus

The first part is about the following improvement:

As an Editor using the link toolbar to search for knowledge to reference in my article, I can see specific articles as the first search results.

This effects the link search function in VisualEditor and the 2017 wikitext editor.

The change should go live this week. In the meantime, if you would like to preview the changes, you can try it out on the beta cluster. For instance, when adding a link and you type out the term "New York", New York City and New York (state) appear above the disambiguation page New York in the search results.

We are looking forward to hearing your feedback!

After this change is released, we will be monitoring the numbers inside The Daily Disambig to see if it has any impact on the number of unwanted dab links being added (thanks for pointing us in the direction of this page).

23 juillet 2021 : Avertir lors de l’ajout d’un lien vers une page d’homonymie

We have begun design planning on this wish. Our designer, NAyoub is working on setting up some user tests where we ask new editors to link from the Jupiter article to the Mars article and see if they fall for the disambiguated page since it's the first result. We will take notes and write up next steps based on the results. Our engineers are also investigating the feasibility of moving search results for disambiguated terms to the bottom of the results. En savoir plus

16 juillet 2021 : Copier-coller les diffs

Nous commençons à travailler sur l’outil de copier-coller des diffs. Nous nous posons des questions sur son design. Nous vous invitons à y répondre sur la page de discussion du projet. En savoir plus

Étude technique

Nous avons commencé l’étude technique pour ce travail. Nous sommes optimistes quant à la solution trouvée pour corriger le problème.

Vidéo montrant les interactions nécessaire pour sélectionner dans un diff afin de copier et coller.

Questions ouvertes

• Dans quels contextes les utilisateurs copie-collent-ils des éléments de diffs ?
• Quels éléments supplémentaires se révèlent intrusifs ? Certains éléments hors code devraient-ils être conservés lors du copier-coller ?
• Que pensez-vous la solution que nous proposons ?

15 juillet 2021 : état actuel

There have been and will be changes to our team. We have made decisions what will be the sequence of wishes we will be working on. We would like you to learn more about our methodology. There are reasons why the voting is not the only criterion. Please tell us what you think about it. En savoir plus