•  ontereh-licht

MTR: meerdere vertalingen

vertaaldiensten inpakken voor intern gebruik

Bij het publiceren van een website wil je misschien verschillende vertalingen aanbieden. Sommige mensen houden niet van geautomatiseerde vertalers, ik denk dat een geautomatiseerde vertaling goed genoeg is, en beter dan niets, en geautomatiseerde vertalers zijn steeds beter geworden met de vooruitgang in NLP en ML.

Veelgebruikte vertaaldiensten zijn google, bing, yandex. Deze bieden een gratis laag die we willen inpakken voor ons eigen persoonlijk gebruik. Er zijn ook andere minder bekende vertaal diensten , en sommige zijn afgesloten op het moment van schrijven...

Tekst in cache plaatsen

Als we vertalingen willen cachen, moesten we de gevraagde tekst opsplitsen in kleinere strings, zodat ze klein genoeg zijn om treffers te leveren voor mogelijke toekomstige verzoeken. De compromis is dat de vertaling van kleinere zinnen minder context heeft, wat de kwaliteit van de vertaling verlaagt.

Hoe kunnen we binnenkomende tekst zo splitsen dat we het origineel uit de vertaalde tekst kunnen reconstrueren is nogal een truc..of een hack. We willen een string zo raar vinden dat de vertaalservice hem verlaat zoals het is in zijn uitvoer. Ik heb variaties gevonden op de alinea teken om de meeste tijd te werken

$this->misc['glue'] = ' ; ¶ ; ';
$this->misc['splitGlue'] = '/\s?;\s?¶\s?;?\s?/';

Deglue string wordt gebruikt om samen te voegen alle de strings (gesplitst van het oorspronkelijke verzoek) in een enkele instantie voor het upstream-vertaalverzoek dat we naar b.v. google. DesplitGlue wordt in plaats daarvan gebruikt om de ontvangen vertaling op te splitsen in de strings die we gaan cachen. We zien hier dat het splitsen van strings niet alleen handig is voor caching, maar ook om het aantal verzoeken verminderen, omdat in het geval dat ons downstream-verzoek veel kleine zoekopdrachten uitvoert, we onze machines gebruiken om verzoeken samen te voegen tot de maximale payload-grootte die is toegestaan ​​door de upstream-service.

De interface

Om meerdere diensten te ondersteunen transparant Ik heb een interface geschreven die op deze API is gebaseerd

function__construct(
    Mtr &$mtr,
    Client &$gz,
    TextReq &$txtrq,
    LanguageCode &$ld);
functiontranslate($source, $target, $input);
functiongenReq(array$params);
functionpreReq(array &$input);
functiongetLangs();

Een dienst die operationeel moet zijn, moet dus een vertaalfunctie bieden, aanvragen vertalen en een lijst met ondersteunde talen bieden. Met de lijst met ondersteunde talen kunnen we een matrix maken zodat we weten hoeveel services een specifieke taalparen ondersteunen, voor het ontleden van de taalparen we converteren de representatie die door de service wordt geretourneerd naar een commoniso639-1.

Het maken van de vertaalinstantie maakt het ook mogelijk om de verzoekopties te configureren die worden gebruikt doorGuzzle client-instantie, zodat we bijvoorbeeld proxy's kunnen gebruiken om de verzoeken uit te voeren. De diensten zijn: gecached nadat het de eerste keer is gegenereerd, is dit handig omdat sommige services een aantal initiële tokens moeten genereren en we deze niet elke keer opnieuw willen genereren.

De Go-versie

ik schreef ook een versie in golang. De PHP-versie zou worden gebruikt door deze in uw PHP-project te importeren, terwijl de go-versie werkt als een zelfstandige (micro) service. De go-versie is veel uitgebreider omdat het strikte typecontrole vereist en omdat we ondersteuning bieden voor het tegelijkertijd opvragen van meerdere strings, moeten we api blootleggen die werkt met verschillende invoercombinaties, en het ontbreken van go-generieken maakt de implementatie erg pijnlijk, maar het bood gelijktijdige verwerking, en was over het algemeen veel sneller.

Reinigingsingangen

In combinatie met de vertaling heb ik ook een service gebouwd om html opschonen . We zetten enkele html-tags op de witte lijst en verwijderen de rest. We verwijderen ook spamachtige dubbele interpunctie en onbekende html-kenmerken, en plaatsen links in de juiste ankertags.

Zelf gehost:

conclusies

Tegenwoordig denk ik dat ik gewoon een zelf gehoste oplossing zou gebruiken, geleverd door joshua of argos, aangezien ik niet streef naar de beste vertaling, ik wil een leesbare vertaling voor een website aanbieden, zodat deze zonder wrijving kan worden genavigeerd.

Berichttags: