Themen dieser Woche waren unter anderem eine API für eigene Felder im Backend, die konsistente Behandlung von Backend-Links sowie die weitere Verbesserung von Filtermöglichkeiten auf translate.WordPress.org.
Core
Übersetzung von Nicht-Gettext-Strings ermöglichen
Im Chat des Multilingual-Projekts ging es um die Implementierung einer Lösung für die Übersetzung von Nicht-Gettext-Strings wie etwa dem Blog-Titel, der -Beschreibung und der Autoren-Beschreibung. In seinem Vorschlag im Multilangual-P2 hat Andrea Sciamanna, Lead-Entwickler von WPML, einen Lösungsansatz via Filter vorgestellt.
Diese Lösung würde keine Änderungen im Core voraussetzen sondern eher eine Konvention sein, die beispielsweise in Multilingual-Plugins integriert würde. Gespeichert werden könnte die Übersetzung dann etwa in einer pot- oder mo-Datei (was wohl performanter ist). Marko Heijnen, Lead-Entwickler von GlotPress, ist der Meinung, dass die Lösung direkt in WordPress integriert werden sollte und sich Plugin- und Theme-Entwickler keine Gedanken um die Implementierung machen sollten. In der anschließenden Diskussion sind die Meeting-Teilnehmer übereingekommen, dass ein alternativer Lösungsvorschlag erarbeitet wird, damit beide gegenübergestellt werden können.
Probleme mit Shortcodes innerhalb von Spitzklammern
Nach dem Release von WordPress 4.2.3 gab es Probleme mit Shortcodes, die innerhalb von Spitzklammern geschrieben wurden (#33116). Der Fehler wurde mit dem Release von WordPress 4.2.4 behoben.
Fields-API
Scott Kingsley Clark arbeitet an einer API für eigene Felder im Backend. Sie basiert auf der Customizer API und soll es ermöglichen, „zu jedem Objekt in einem Standard-Interface ein Feld hinzuzufügen“. Verständlicher ausgedrückt: Ihr könnt damit Felder und Bereiche in Backend-Seiten integrieren, zum Beispiel einen Bereich „Social Media“ auf den Benutzerseiten und diesem dann Felder für die gängigen sozialen Netzwerke zuweisen.
Nähere Informationen zu der API findet ihr im Beitrag von Scott in dem Make/Core-Blog.
Änderungen in Listen-Tabellen
In kleinen Viewports wurden bisher beispielsweise in der Übersicht der Beiträge Informationen komplett ausgeblendet, etwa die Kategorien und Schlagworte. Das ist nicht optimal, da der Nutzer dann einen Klick mehr tätigen muss, um an Informationen zu kommen, die auf größeren Viewports sofort zugänglich sind und eventuell die Entscheidung, auf den Link zur Detail-Ansicht zu klicken, beeinflussen würden.
In WordPress 4.3 werden diese Informationen überall zugänglich sein, auf kleinen Displays zwar eingeklappt aber über einen Pfeil ausklappbar. Nähere Infos zu den Änderungen, auch für Entwickler interessant, findet ihr im Make/Core-Blog im Beitrag von Helen Hou-Sandi.
Diverses
- Samuel Sidler hat im Make-Blog die Änderungen in WordPress 4.3 zusammengefasst
Accessibility
Bessere Zugänglichkeit für die Export-Seite
Vor drei Wochen wurde im Core-trac das Ticket #33046 erstellt, in dem Andrea Fercia Verbesserungen bei der Zugänglichkeit für die Export-Seite in WordPress vorschlägt. Vom 23. bis 30. Juli wurden daraufhin Tests durchgeführt, deren Ergebnisse am 3. August im Accessibility-Bereich der Make-Blogs veröffentlicht wurden. Aus den Tests ergeben sich folgende Empfehlungen für Verbesserungen:
- Den visuellen Fokus der Radiobuttons prüfen (Firefox auf Mac hebt bei einem Tastatur-Nutzer den aktuell ausgewählten Button nicht hervor)
- Ein
for-Attribut bei den Beschriftungen der Auswahlfelder einfügen, damit die Beziehung klar ist - Eine andere Beschreibungsstruktur für die Auswahl von Start- und Enddatum des Exports finden
- Versuchen, die Navigationsprobleme mit NDVA (ein Screen-Reader) von der Testerin Michelle DeYoung zu reproduzieren und zu klären
Konsistente Behandlung von Links im Backend
Bisher gibt es einige Links im WordPress-Backend, die in einem neuen Fenster oder Tab geöffnet werden. Bereits im Team-Chat der letzten Woche kam das a11y-Team zu dem Schluss, dass kein Link automatisch in einem neuen Fenster/Tab geöffnet werden soll, um die Konsistenz zu wahren. Noch nicht ganz klar war zu diesem Zeitpunkt, wie der Verlust von geänderten Einstellungen auf einer Seite verhindert werden kann, wenn ohne Speichern auf einen Link geklickt wird.
Im dieswöchigen Chat wurde sich erst einmal darauf geeinigt, dass für diesen Zweck eine Warnung per JavaScript ausreichend und kein automatisches Speichern notwendig sei. Das dazugehörende Ticket im Trac ist #23432.
Längerfristig planen auf Make/Accessibility
In dem Chat dieser Woche kam noch zur Sprache, dass das a11y-Team einen Platz auf Make/Accessibility benötigt, wo längerfristige Ziele festgehalten werden können. Rian Rietveld hat das Thema angesprochen:
„With tickets we can't make big steps, only tiny changes, baby steps[.] But we need a space where we can write down our long time goals for WordPress. And work on them together.
What about the following: Pages on make/accessibility with issues, things we want to change in WordPress, like:
Colour contrast
Heading structure
Label/input relation
[...]Per page a short paragraph with a description of our goal for that item, links to documumentation and guidelines and a list of current tickets that needs work
That way we can focus on getting one issue done and also refer to that page if new functionality gets added wrong.“Rian Rietveld im #accessibility-Slack-Channel
Die Idee wurde gut aufgenommen und wird wohl umgesetzt werden.
Popup-Hinweise im Backend
Aus Accessibility-Sicht sind die Popup-Hinweise im Backend verwirrend und lassen sich zudem beispielsweise per Tastatur nicht ausblenden. Einige Mitglieder des Teams sind dafür, dass diese Hinweise komplett entfernt werden – im #core-Channel wurde beschlossen, dass alle diese Hinweise entfernt werden und keine neuen hinzukommen werden.
Meta
Filterung/Sortierung der Übersetzungs-Projekte
Samuel Sidler hat sich Gedanken über eine bessere Sortierung und Filterung der Projekte auf translate.WordPress.org gemacht. Als oberste Priorität sieht er einen Tab der Übersetzungen auflistet, die nur noch akzeptiert werden müssen. Des Weiteren müssen Standard-Prioritäten eingeführt werden, wichtig vor allem für die Plugins und Themes. In jedem Tab muss es dann die Möglichkeit geben, nach Punkten wie der Popularität im Repository oder anderen zu filtern.
Als vierte Priorität nennt Sam zukünftige Filter wie etwa eine Filterung danach, wie lange ein String bereits auf Annahme wartet. Nähere Infos findet ihr im Beitrag von Sam in dem Make/Meta-Blog.
Theme Directory/Theme Review
Tags im Theme Directory
Wie bereits letzte Woche ging es auch diesmal wieder um die Überarbeitung der Tags des Theme Directorys. In seinem Beitrag vom 3. August hat Justin Tadlock auf Make/Themes mögliche Tags zur Abstimmung gestellt. Die Themen-Tags sollen stark erweitert werden, die Farb-Tags sowie das Blavatar-Tag sollen entfernt werden. Diese Verbesserungen waren auch Thema des Meetings, wo die Vorschläge besprochen und angepasst wurden.
Update des Theme-Check-Plugins
Samuel Wood (aka Otto) hat sein Theme-Check-Plugin auf GitHub aktualisiert. Es enthält nun auch einen Text-Domain-Test:
„The text-domain check tells you what the directory name/slug for the theme should be, given the name, and it also tells you what text-domains are being used in the theme, and if there's more than one of them.“
Samuel Wood im #themereview-Channel in Slack
Feaure-Plugins
Responsive Images
Bei dem Feature-Plugin, dass responsive Images mit srcset- und sizes-Attributen in den Core bringen soll, wird aktuell an einer Lösung gearbeitet, um bereits vorhandene Bilder in Beiträgen und Seiten zu aktualisieren. Bisher kümmert sich das Plugin nur um Bilder, die nach der Installation eingefügt werden.
Fehlt euch hier etwas wichtiges? Dann schreibt es in einen Kommentar und ich nehme es noch mit auf!