WordPress-Wochenrückblick KW1: WordPress-4.5-Kickoff, WordPress 4.4.1 und mehr

In der letzten Woche hat das Core-Team offiziell die Phase des 4.5-Releases gestartet. Zudem wurde mit WordPress 4.4.1 ein Sicherheits- und Wartungs-Release veröffentlicht.

Accessibility

Im a11y-Meeting wurden zunächst einige Tickets diskutiert. So gibt es bei dem Suchformular, das im Backend und in Themes genutzt wird, einige Redundanz für Screen-Reader-Nutzer. Als recht einfache Maßnahme dagegen wurde festgehalten, das title-Attribut zu entfernen – in Changeset 36222 wurde sie auch gleich umgesetzt. Zudem hat Joe Dolson einen aktualisierten Link zu den Code-Richtlinen mit Blick auf Accessibility gepostet.

Um das Beitragen zur Dokumentation zu vereinfachen, wird Trisha Salas in nächster Zeit Unterkategorien und -Seiten erstellen, damit von neuen Contributorn nicht erst auch eine Struktur erstellt werden muss. Genauere Infos zu dem Meeting findet ihr in dem Make-Post von Trisha.

Core

WordPress 4.4.1

Am 6. Januar wurde mit 4.4.1 ein Sicherheits- und Wartungs-Release veröffentlicht, der eine XSS-Lücke schließt. Darüber hinaus wurde der Emoji-Support aktualisiert, sodass die neuesten Emojis eingesetzt werden können. Zudem wurde ein Problem mit älteren OpenSSL-Versionen sowie falschen Weiterleitungen behoben. Genaueres gibt es auf de.WordPress.org oder im Originalbeitrag auf WordPress.org.

WordPress 4.5 – Kickoff

Im Kickoff-Meeting wurde zunächst Adam Silverstein als Release-Stellvertreter sowie Mel Choyce als Design-Stellvertreter vorgestellt – Mel wird für eine konsistente Einhaltung des Designs sorgen. Die Bug-Scrubs wird Chris Christoff leiten. Die Release-Planung sieht vor, dass die neue Version am 12. April veröffentlicht wird.

Als nächstes ging es im Meeting um die verschiedenen Bereiche, an denen Contributors für 4.5 Interesse gezeigt haben. Dabei sollte es um die generellen Interessen gehen – Feature-Plugins sollen im Dev-Chat nächster Woche Thema sein, der am 12. um 22 Uhr beginnt.

Customizer

Weston Ruter hat drei Bereiche aufgeführt, die ihm als Feature-Plugins in den Sinn kommen:

  • Die Möglichkeit, den Customizer (die linke Seite mit den Einstellungsmöglichkeiten) zu vergrößern/verkleinern (#32296)
  • Die Möglichkeit, im Customizer eine Vorschau für verschiedene Geräte anzuzeigen, wie Tablet und Smartphone (#31195)
  • Bessere Validierung von Customizer-Einstellungen (#34893)

Eine Demo das Feature-Plugins zum letzten Punkt gibt es auf YouTube:

https://www.youtube.com/watch?v=ZNk6FhtS8TM

Eine weitere wünschenswerte Funktion wäre, dass gleich aus dem Customizer heraus Elemente erstellt werden können, die zu einem Menü hinzugefügt werden können. So müsste ein neuer Nutzer, der durch den großen „Anpassen“-Button zuerst im Customizer gelandet ist, für die Erstellung eines Menüs nicht den Customizer verlassen, um erst eine Seite oder ähnliches anzulegen (#34923) – hierbei ist nicht die Rede von einem vollwertigen WordPress-Editor, sondern nur von einem Feld für einen Titel.

Zudem soll es möglich werden, Customizer-Einstellungen so zu sichern, dass sie ohne vorheriges Speichern auch nach einem Browser-Crash noch da sind (#30937), und bei der Änderung einer Einstellung nur diese in der Vorschau neuzuladen (#27355).

Weitere Verbesserungen

Weitere potenzielle Verbesserungen und neue Funktionen für 4.5, über die noch nicht so viel gesagt wurde, sind folgende:

  • Verbesserung des Workflows beim Veröffentlichen
  • Verbesserung der Komprimierung von den Bildern, die WordPress erzeugt
  • Problemloses Funktionieren von WordPress mit SSL – kein Mix aus http- und https-Ressourcen mehr
  • Erste Arbeiten an Kommentarbearbeitung und Kommentar-Typen

Flow

User-Testing des „Shiny Updates“-Plugins

Auf Make/Flow wurden ein paar User-Tests zu dem Feature-Plugin „Shiny Updates“ veröffentlicht. Zwei behandeln den normalen Plugin-Installationsprozess, einer den Prozess inklusive der Nutzung des neuen Features.

Polyglots

Technisches

Auf den Team-Seiten sind Project-Translation-Editors (PTEs) und General-Translation-Editors (GTEs) nun getrennt und auf der Credits-Seite des WordPress-Backends nur noch die PTEs und GTEs aufgeführt, die zum WordPress-Core beigetragen haben, nicht die, die „nur“ ein Plugin oder Theme betreut haben. Weitere Tech-Updates gibt es im Slack-Post von Dominik Schilling.

Ziele

Als Ziele für 2016 wurden folgende formuliert:

  • Mit lokalen Teams daran arbeiten, die Starter-Guides zu verbessern
  • 100 veröffentlichte Sprachversionen für den letzten WordPress-Release in 2016
  • Top-100-Plugins und -Themes zu mehr als 50 Prozent in den 50 aktivsten Sprachen übersetzt
  • Übersetzungs-Management und Kommunikationstools verbessern
  • Die Sichtbarkeit des Polyglots-Teams im WordPress-Ecosystem verbessern und eine Anerkennung des Teams bei Release-Posts erreichen (wird bisher nicht erwähnt)
  • Die Zahl aktiver Translation-Editors je Sprache erhöhen
  • Das Leadership-Team in den asiatischen/pazifischen Raum erweitern

Was tun, wenn Strings aus rechtlichen Gründen kritisch sind?

Bei einem Plugin gab es für die deutsche Übersetzung folgendes Problem: Das Plugin hat mit Superlativen für sich geworben (in der Form „das beste …“), was im deutschen ohne Beleg nicht erlaubt ist. Hier wurde die Frage geklärt, wie mit solchen Strings umgegangen werden sollte: Ob eine Abwandlung an das lokale Recht in Ordnung ist oder anders verfahren werden soll.

Der aktuelle Stand ist, dass der Plugin-Autor im Plugin-Support-Forum darüber informiert werden soll. Falls keine Antwort kommt und der Autor den Original-String nicht anpasst, kann der Übersetzer die Übersetzung so vornehmen, dass sie rechtlich unbedenklich ist, soll diese Veränderung aber in demselben Thread des Support-Forums kommunizieren, in dem der Autor über den problematischen String informiert wurde.

Mehr aus dem Meeting gibt es im Beitrag von Petya Raykovska auf Make/Polyglots.

Team-übergreifend

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.