Eine alternative Möglichkeit zur Lokalisierung von Websites: Mutanter CDN-Inhalt

Eintrag


Die meisten Webentwickler mussten eine Website in mehrere Sprachen übersetzen. Die Mission ist recht einfach und die Lösung bezieht sich in der Regel auf die Routine. Ich bin sicher, dass viele der Aussage zustimmen werden, dass Lokalisierung ein langweiliger, nicht kreativer Teil des Projekts ist.

In diesem Artikel möchte ich ein alternatives Website-Übersetzungsmodell zur Diskussion stellen. Wenn Sie versuchen, das Prinzip in einem Satz zu beschreiben, dann ist es: CDN, das den Inhalt zwischen dem Benutzer und der Originalquelle übersetzt.

Die Notwendigkeit von Übersetzungen


Ich bezweifle, dass es sich lohnt, den Nutzen der Mehrsprachigkeit der Ressource zu beweisen, aber ich widme dem dennoch einen kleinen Absatz.

Jede Internet-Site ist standardmäßig für drei Milliarden Benutzer auf der Welt zugänglich - einfach, weil sich Ihre Site im Internet befindet. Wenn Sie etwas auf der Website verkaufen, dann betreten Sie durch einfaches Hinzufügen einer Sprache einen neuen Markt. Sie sollten mindestens eine Version in der Landessprache (der Sprache des Gebiets, in dem Sie geschäftlich tätig sind) und die englische Version haben, da Englisch laut W3Techs die Hälfte des Internetinhalts ausmacht .

Bestehende Methoden


Übersetzungsdateien


Es gibt verschiedene Optionen - von speziellen Formaten wie GNU gettext bis zu einfachen Textdateien, die Ihr aktuelles Framework verwenden kann. Das Ergebnis ist ungefähr dasselbe: Zum Zeitpunkt der Textausgabe wird eine Funktion aufgerufen, die nach der Übersetzung im Wörterbuch sucht.

PHP Beispiel:

// gettext:
echo _("Привет, мир!");
// Фреймворк Laravel 5
echo trans('common.hello_world');

Vorteile der Methode:

  • Bewährte jahrzehntelange Methode (lesen Sie das Übliche);
  • Die Möglichkeit, einzelne Dateien einfach an Übersetzer von Drittanbietern weiterzugeben.
  • Wenig Einfluss auf den Code.

Nachteile der Methode:

  • In der Regel gibt es keine Möglichkeit, sofort Änderungen vorzunehmen;
  • gettext-Wörterbücher müssen kompiliert und endgültige Dateien an das Repository übergeben werden.
  • Relativ unpraktisches und langsames Textmanagement: Je größer das Projekt, desto mehr Dateien und verwirrende Hierarchien.
  • Es gibt keine Standardmechanismen für die Bearbeitung von Übersetzungen durch ein Übersetzerteam.
  • In der Regel werden zwei Schemata parallel verwendet - Übersetzungen für das Backend und Übersetzungen für das Frontend (JavaScript);
  • Von Zeit zu Zeit erscheinen HTML-Tags in Texten für Übersetzungen, da es für Programmierer unpraktisch war, sie herauszuholen.

Datenbank-Übersetzungen


Im Gegensatz zur ersten Methode werden Übersetzungen in der Projektdatenbank gespeichert, sodass Sie Anpassungen auch unterwegs vornehmen können. In der Regel erstellen Projektentwickler ein Übersetzungssteuerfeld für Administratoren, was zusätzliche Zeit in Anspruch nimmt.

Vorteile der Methode:

  • Einfachere Organisation der Arbeit von Teams;
  • Die Fähigkeit, sofort Änderungen vorzunehmen.

Nachteile der Methode:

  • Es ist schwieriger, Abschnitte für die Übersetzung an Fremdübersetzer zu vergeben.
  • Frontend-Texte werden weiterhin getrennt von Backend-Texten übersetzt.
  • Von Zeit zu Zeit erscheinen HTML-Tags in Texten für Übersetzungen, da es für Programmierer unpraktisch war, sie herauszuholen.

Benutzerseitige Übersetzung über JavaScript


Eine relativ neue Methode, die mittlerweile von mehreren westlichen Startups angeboten wird. Sie müssen lediglich einen Link zu einer externen JavaScript-Datei hinzufügen, die Texte im DOM basierend auf den zuvor bereitgestellten (oder genehmigten) Übersetzungen ersetzt.

Vorteile der Methode:

  • Einfache Installation mit wenig bis gar keiner Programmierung;
  • Frontend und Backend werden simultan aus einem Übersetzungs-Repository übersetzt.
  • Das Text-Repository enthält keine HTML-Tags, da alle Texte post factum aus dem DOM verarbeitet wurden.

Nachteile der Methode:

  • Suchmaschinen sehen keine zusätzlichen Sprachen.
  • Das Teilen des Links in sozialen Netzwerken ist ebenfalls nicht möglich.
  • Zusätzliche Netzwerklast (lesen Sie das Risiko von Verzögerungen), wenn Sie die Site öffnen.

CDN-Übersetzer


Eigentlich, was in diesem Artikel zur Diskussion gebracht wird. Was aber, wenn zwischen dem Benutzer und den Websites eine „Ebene“ eingefügt wird - ein Edgeserver, der in der Lage ist, Webinhalte zu übersetzen? Dienste wie CloudFlare wissen bereits, wie man Clientseiten minimal verändert - fügen Sie beispielsweise Google Analytics-Code hinzu. Was ist, wenn wir einen Schritt weiter gehen und dem Benutzer erlauben, Texte und Links zu ersetzen?

Herkömmliches CDN-Verhalten:

  1. Der Client fordert die Adresse X an.
  2. Befindet sich die Adresse X im Cache, wird sie sofort vom Cache zurückgegeben.
  3. Befindet sich die X-Adresse nicht im Cache, sendet der Edgeserver eine Anforderung an die ursprüngliche Site und gibt dann eine Antwort an den Client zurück. Abhängig von den Kopfzeilen in der Antwort der ursprünglichen Site und den auf der Site festgelegten Regeln kann Ressource X jetzt zwischengespeichert werden.



CDN-Übersetzerverhalten:

  1. Der Client fordert die Adresse X an.
  2. Befindet sich die Adresse X im Cache, wird sie sofort wie sie ist aus dem Cache zurückgegeben.
  3. Befindet sich die X-Adresse nicht im Cache, fordert der Edgeserver die ursprüngliche Site an und wendet dann die Mutationsregeln an. Ersetzt Links und ersetzt übersetzte Texte. Abhängig von den Kopfzeilen in der Antwort der ursprünglichen Site und den auf der Site festgelegten Regeln wird Ressource X möglicherweise zwischengespeichert.

Schritt 2b im Detail


Nach dem Empfang einer Antwort von der ursprünglichen Site steht der Border-Server vor der Aufgabe, diese zu übersetzen. Vorgeschlagene Taktik:

  1. Achten Sie auf den Content-Type-Header. Wenn der Wert nicht in der Liste der unterstützten Werte enthalten ist, versuchen Sie nicht, den Inhalt zu transformieren.
  2. Achten Sie auf die Größe der Antwort. Wenn die Größe über dem festgelegten Rand liegt, versuchen Sie nicht, den Inhalt zu transformieren.
  3. Starten Sie das Parsen und Bearbeiten von Inhalten. Beispiel für eine HTML-Seite: Gehen Sie durch alle DOM-Knoten, die einen Text-Nachfolger-Knoten haben. Fordern Sie den übersetzten Text im Repository an und übergeben Sie den Quelltext und den Kontext als Parameter.
  4. Ersetzen wir die benötigten Inhalte, geben wir das Ergebnis an den Nutzer zurück. Wenn die Überschriften und Regeln dies zulassen, wird das Ergebnis zwischengespeichert.

Es wäre logisch, das Repository als freistehende RESTful-API zu implementieren, und es wäre praktisch, den Kontext wie URL: Selector festzulegen. Zum Beispiel möchten wir das Wort "Hauptseite" in jedem Block einer Seite, der mit / news beginnt, als "Startseite" übersetzen. Wir erhalten den Kontext "/ news *: head". Die Welt ist so an CSS / jQuery-ähnliche Selektoren gewöhnt, dass fast jeder Entwickler in der Lage sein wird, sofort mit dieser Syntax zu arbeiten.

Da der Grenzserver die Übersetzung in die Repository-API anfordert, ist die Implementierung von SDK und Paketen für gängige Sprachen und Frameworks völlig logisch. Website-Besitzer haben die Wahl - Sie können Inhalte über CDN übersetzen, Sie können durch unsere Klasse in den vorhandenen Code.

Angenommen, wir haben eine PHP-Anwendung und verwenden das Laravel-Framework. Die Implementierung von Legacy-Unterstützung ist trivial - wir deklarieren die trans () - Hilfsfunktion neu und ersetzen sie durch unsere Implementierung, bei der die Suche nicht in lokalen Textdateien, sondern in der Remote-API erfolgt. Um Verzögerungen bei jeder Anfrage zu vermeiden, verwenden wir einen Cache oder einen separaten Proxy-Prozess.

Ebenso können wir den Inhalt von JavaScript-Objekten, Grafiken usw. ändern.

Vorteile der Methode:

  • Vollständige Abstraktion der Anwendung und Übersetzungen - Die Anwendung weiß überhaupt nicht, ob andere Sprachversionen verfügbar sind. Programmierer arbeiten ruhig am Hauptprodukt;
  • Backend- und Frontend-Inhalt werden gleichzeitig mit einem Übersetzungs-Repository übersetzt.
  • Sie können einfach grafische Bilder übersetzen.
  • Es ist sehr einfach, übersetzte Versionen der Site auf anderen (separaten) Domänen auszuführen.
  • Kompatibel mit allen vorhandenen CDN-Diensten. Kann in einer Kette angeordnet werden;
  • Kompatibilität mit Suchmaschinen und sozialen Netzwerken;
  • Das Text-Repository enthält keine HTML-Tags, da alle Texte post factum aus dem DOM verarbeitet wurden.
  • Einfach zu organisierende Teamarbeit.

Nachteile der Methode:

  • Ich konnte nicht finden, aber ich werde sehr gerne dabei helfen!

YouTube-Video


Um das Konzept klar zu erklären, habe ich einen kurzen Videoclip gedreht, der meinen Prototyp eines solchen Übersetzungssystems zeigt. Narrative in Englisch, aber ich habe russische Untertitel hinzugefügt.



Implementierung


Ich habe bereits die Machbarkeit und Praktikabilität der vorgeschlagenen Methode überprüft - ich habe eine primitive Version der Border-Anwendung in PHP und Lumen geschrieben.

Meine Methode, eine Anfrage vom Benutzer erhalten und die übersetzte Antwort zurücksenden:

/**
 * @param Request $request
 * @param WebClientInterface $crawler
 * @param MutatorInterface $mutator
 * @param TranslatorInterface $translator
 * @return Response
 */
public function show(Request $request, WebClientInterface $crawler, MutatorInterface $mutator, TranslatorInterface $translator)
{
    $url = $request->client['origin'] . parse_url($request->url(), PHP_URL_PATH);
    $response = $crawler->makeRequest($request->getMethod(), $url);
    if ($response === false) abort(502);
    $mutator->initWithWebRequest($response);
    if ($response->isTranslatable()) $mutator->translateText($translator);
    if ($response->isCacheable()) $mutator->cache(60);
    $mutator->replaceLinks($request->client['origin'], $request->getSchemeAndHttpHost());
    return (new Response($mutator->getBody(), $mutator->getStatusCode()))
        ->withHeaders($mutator->getHeaders());
}

Ich bin mir sicher, dass viele aufgrund der Prozessorauslastung anfangen werden, an dem Paradigma zu zweifeln - schließlich möchte derselbe Nginx den Inhalt der Antworten nicht in irgendeiner Weise verändern, was sich sehr negativ auf die Leistung auswirken würde. In der Regel ist eine solche Übersetzung nach dem Faktum mit Sicherheit ressourcenintensiver.

Meine Argumente sind wie folgt. Die Kosten für IT-Ressourcen sind in den letzten fünf bis zehn Jahren stetig gesunken. Die Server-Ära hat 5 US-Dollar gekostet. Für viele Websites ist es nicht so beängstigend, die Auslastung ein wenig zu erhöhen. Zweitens, wenn ich mich an diesem Projekt beteilige, wird die Leistungsoptimierung einer der Schwerpunkte sein. Sie können sicherlich viele Orte für Verbesserungen finden!

Fazit


Die Branche strebt immer nach Optimierung, erhöhtem Komfort und Kosteneinsparungen. Ich glaube, dass die vorgeschlagene Methode zur Lokalisierung von Webanwendungen sehr wahrscheinlich in 5-10 Jahren zur Hauptmethode wird.

Darüber hinaus kann CDN als Struktur immer neue Anwendungen haben. CloudFlare bot den weltweiten DDoS-Schutz, Imgix erstellt reaktionsschnelle Bilder.

Jetzt auch beliebt: