Projekt:Wikispeech – Talresursinsamlaren 2019/WMDE site visit 2020-01-20–24

Wikimedia Sveriges (WMSE) site visit hos Wikimedia Deutschland (WMDE) ägde rum mellan 20:e och 24:e januari 2020 på WMDEs huvudkontor i Berlin. Syftet var dels att skapa en samstämmighet i terminologi och dokumentationsstil för att underlätta framtida kommunikation, dels att mer intensivt och iterativt kunna undersöka olika aspekter och frågor.

Huvudfokus var på följande frågor:

• Hur ska WMDEs framtida kodgranskning och återkoppling fungera, både när det gäller Text-till-tal (TTS) komponenten och Taldatainsamlaren.
• Vilka delar av TTS komponenten (MediaWiki-tillägg och Speechoid) kan behöva åtgärdas för att bereda vägen för att WMF godkänner implementering på Wikipedia
• Guidning i de olika stegen som ingår i att ta TTS-komponenten från dagens läge till full implementering på Wikipedia
• Förpackning av TTS komponenten för både kod-/säkerhetsgranskning och senare driftsättning

Utöver dessa mer tekniska aspekter ägde även möten rum som såg till hur WMSE kunde dra nytta av WMDEs organisatoriska erfarenheter. Dessa möten inkluderar, men var ej begränsade till:

• Product Managment
• Recruitment processes for developers
• How to start and run Software Products
• Do's and dont's when developing on Wikipedia
• Office tech setup

Utöver mötena fick vi även ta del av tillhörande intern dokumentation samt information kring The Journey Model som är det ramverk för utveckling och team som används av WMDE.

Både vi och WMDE upplevde att besöket var givande och att en längre fysisk närvaro möjliggjorde utbyte som skulle varit svårt till omöjligt att uppnå per distans. Utifrån denna erfarenhet planerar vi att genomföra ytterligare site visits senare under året.

Framtida Kodgranskning

WMDE kommer även i framtiden att kunna granska vår kod vid begäran. Detta kan antingen göras på en individuell patch där vi känner att de kan fylla i en kunskapslucka från vår sida, alternativt efter att en mindre samling av ändringar har gjorts där vi önskar stämma av att helheten är i linje med Best Practices.

WMDE kommer även att kunna ge stöd under den (tekniska) planeringsfasen av nya komponenter eller delkomponenter vid behov genom att ge återkoppling kring vår planerade implementering redan innan vi börjar skriva någon kod.

Paketering och driftsättning

WMF har gått över till att använda Blubber för paketering och driftsättning av tjänster. Detta system är nytt men har fördelen att det är mindre komplicerat än Puppet så länge det finns en baseimage för det språk som används (eller om denna kan kompileras till en binär). Vi har även fått bekräftat att vi kan påbörja arbetet med att bygga dessa innan säkerhetsgranskningen är gjord. Varje tjänst (wikispeech_mockup, MaryTTS, Pronlex, etc.) måste ha sitt eget repo på gerrit samt sin egen Blubber-fil som i sin tur skapar en egen Docker-image.

Det är ännu inte klart om var av dessa slutligen kör som separata tjänster eller som en enskild tjänst som kapslar in de övriga. Beslut om detta skulle behöva en officiell Request for Comments.

Steg-för-steg från påbörjad kod till aktivering på Wikipedia

Tillsammans med WMDE identifierade vi samtliga steg som måste tas för att få både MediaWiki-tillägget och de bakomliggande tjänsterna aktiverade på Wikipedia. Vi tittade även på vilka mätmetoder som finns för att följa upp användningen av olika aspekter av Wikispeech inkl. att kunna se hur många som väljer att inaktivera den under Beta Feature-perioden.

Detta har gett oss en tydligare bild över nästa steg som vi måste ta, de tidsaspekter som är involverade (t.ex. om vår lösning skapar ett behov av extra hårdvara) samt vilka delar av WMF som är ansvariga och ska kontaktas för var del.

Analyserade aspekter av TTS komponenterna

Lagring av audio

Idag lagras de genererade audiofilerna på den server där wikipeech_mockup körs. WMF har tidigare anmärkt att lagringssättet måste ses över för att passa i deras miljö. Efter att olika möjligheter analyserats drogs slutsatsen att den lämpligaste lösningen är en där wikispeech_mockup skickar filerna till MediaWiki-tillägget och detta sköter lagringen. Denna justering har två huvudsakliga fördelar: 1) MediaWiki kan själv avgöra vilken lagringsmekanism som ska användas genom redan existerande funktionalitet. 2) De tjänster som idag används av Wikimedia är stateless, dvs. ingen persistent data lagras i dem. Denna ändring, samt den som föreslås under Pronlex nedan, skulle göra att även Speechoid blir stateless.

Frontend/MediaWiki-tillägget

Ett antal frågor lyftes kring den nuvarande implementeringen av MediaWiki-tillägget. Utvalda listas nedan:

• Hur hanterar vi felmeddelanden, om t.ex. tjänsten är nere, om användaren inte kan läsa?
• Hur förhindrar vi att JavaScript laddas ner och körs i onödan, t.ex. när en användare inte är intresserad av att lyssna på sidan.
• Hur kan vi mäta om en användare är nöjd med upplevelsen. T.ex. lyssnar de i snitt bara på de första meningarna eller lyssnar de faktiskt färdigt på artikeln?
• Sidversioner i MediaWiki kan göras osynliga för allmänheten om de t.ex. innehåller förtal eller hot. Hur säkerställer vi att dessa texter inte går att spela upp, alternativt att audio som syntetiserats innan sidversionen doldes inte är nåbara i efterhand.

Backend/Speechoid

Utöver MediaWiki-tillägget består Wikispeech lösningen av en samling backend-tjänster som vi gemensamt kallar Speechoid. Dessa berördes delvis i diskussionen om Paketering och driftsättning samt Lagring av audio ovan.

Pronlex (lexikon)

Idag existerar lexikondatabasen inuti Pronlex-tjänsten. Detta är ytterligare ett fall av en backend-tjänst som inte är stateless (jfr. Lagring av audio ovan). Här finns det dock ytterligare komplikationer då en separat databas skulle kräva en större insats från WMFs drift- och databasadministratörsteam vilket troligen kommer att kraftigt försena möjlig implementering. Att behålla databasen inuti Pronlex skulle även kräva att vi lokalt måste implementera de avlastningsmekansimer (så som att läsa från slavkopior av den databas som skrivs till) vilka redan finns implementerade i MedaWiki.

Av ovanstående anledningar kommer vi därför att undersöka om det är möjligt att flytta lexikondelarna av Pronlex in i MediaWiki-tillägget

MaryTTS/Flite

Det saknas i dagsläget en baseimage för Java (som MaryTTS är skrivet i) samt ANSI C (som Flite använder) vilket förhindrar paketering via Blubber. Det kan vara möjligt att lägga till en sådana baseimages men ett lämpligare alternativ kan vara att kompilera en binär som istället används av Speechoid.

Grov tidsuppskattning för färdigställandet av TTS komponenterna

De timmar som finns i tidplanen/budgeten för detta arbete (Integrering med spelare och Wikimedia-plattformarna) per etapp är [WMSE+STTS]:

• E1 250+50
• E2 400+50
• E3 300+45
• E4 450+25
• E5 240+10

Vilket totalt get 1640h+180h

Vi har satt en intern deadline på September 2020. Tills dess måste vi i alla fall vara ett steg närmare att vara aktiverat på Wikipedia. För oss innebär detta en konkret praktisk åtgärd från WMF (t.ex. försök på Betaklustret). Om denna deadline inte möts måste vi ta ett steg tillbaka och kritiskt granska projektet och dess möjligheter att bli integrerat på Wikipedia.

Aspekter av Wikispeech Text-to-Speech (TTS komponenterna) som måste åtgärdas före betakluster:

• Småpatches [75h + 20h]
  • JS laddning (inkl. interaktivt element för ladda spelaren)
  • Använd standardbibliotek för spelargränssnitt (OOUI)
  • Användarrättigheter för uppläsning
  • Inaktivera för historik
  • GET -> POST för audio syntetisering
  • Bättre dokumentering av wikispeech_mockup
• Lagring av audio och ortografisk data [200h + 20h]
• Pronlex i MediaWiki (eller workaround) [300h + 45h]
• Blubber, paketering (behövs för betakluster) [100h + 15h]
  • Spegla repon i gerrit
  • Kan ske en (tjänst) i taget
• BetaFeature kod [25h]
• Cachning (segmentering åtminstone) [50h]
• Uppskatta prestanda/belastning och storlek (av tjänster och lagring, främst ljud) [25h]
  • Kan göra nu: Storlek på audio (t.ex. hela Barack Obama), Renderingstid (snitt per mening), storlek på tjänsterna idag...
  • Måste vänta till betakluster: Parallella anrops impact på prestandard, ...
• Rate limiting (hur ofta och mycket får tjänst anropas) [50h]

Total tidskuppsakttning: 825h+100h