Mudlet: Richten Sie einen webbasierten Übersetzungsdienst für Mudlet . ein

Erstellt am 9. Apr. 2017  ·  45Kommentare  ·  Quelle: Mudlet/Mudlet

Wir müssen es den Leuten sehr leicht machen, zur Übersetzung von Mudlet beizutragen – das bedeutet etwas Webbasiertes, bei dem die einzige Barriere nur das Einloggen ist. Es könnte einen bestehenden webbasierten Dienst geben, der uns eine Open-Source-Lizenz für die Einrichtung anbieten könnte .

Verfügbare Alternativen:
Launchpad - seine Zukunft ist jedoch fraglich
Transifex - Demoprojekt hier: https://www.transifex.com/mudlet/mudlet/dashboard/

low

Hilfreichster Kommentar

Die Crowdin-Testversion für Jungs läuft in 4 Tagen ab, also brauche ich ein Ja/Nein dazu - wir scheinen bisher damit zufrieden zu sein

Alle 45 Kommentare

Es gibt POEditor als Integration mit github, der die Übersetzung von XLIFF ermöglicht
Dateien (die angeblich von qt linguist unterstützt werden). Und sie haben ein Betriebssystem
Lizenz.

Eine andere Option ist Qordoba, die nichts zu kosten scheint und nativ
ts-Dateien unterstützen.

Ich habe noch nie einen Übersetzungsdienst/eine App verwendet, daher habe ich keine Präferenzen.

Vadim Peretokin [email protected] schrieb am So., 9. Apr. 2017,
13:14:

Wir müssen es den Leuten ganz einfach machen, zur Übersetzung von Mudlet beizutragen

  • das bedeutet etwas Webbasiertes, bei dem die einzige Barriere nur das Einloggen ist.
    Möglicherweise gibt es einen bestehenden webbasierten Dienst, der uns eine
    Open-Source-Lizenz, um das Setup zu erhalten.

Verfügbare Alternativen:
Launchpad https://translations.launchpad.net/ - seine Zukunft ist
aber fraglich


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Mudlet/Mudlet/issues/856 oder den Thread stummschalten
https://github.com/notifications/unsubscribe-auth/ABAeDUJoAsg-zvnOq1YUvuIqn-fbRwcCks5ruL2WgaJpZM4M3_u1
.

Betreff: XLIFF das _Qt Linguist Manual: Translators_ Qt Doc Hinweise:

__Strings übersetzen__
Sie öffnen Übersetzungsquelldateien (TS) in Qt Linguist zur Übersetzung. TS-Dateien sind für Menschen lesbare XML-Dateien, die Quellphrasen und ihre Übersetzungen enthalten. TS-Dateien werden normalerweise von lupdate erstellt und aktualisiert. Wenn Sie keine TS-Datei haben, lesen Sie Release Manager, um zu erfahren, wie Sie eine TS-Datei generieren.
Mit Qt Linguist können Sie auch Dateien im internationalen XML Localization Interchange File Format (XLIFF) übersetzen, die von anderen Programmen generiert werden. Für Standard-Qt-Projekte wird jedoch nur das TS-Dateiformat verwendet. Die unterstützte Mindestversion für Dateien im XLIFF-Format ist 1.1.

Es gibt mittlerweile webbasierte Übersetzungsplattformen, die gegenüber Desktop-Anwendungen enorme Vorteile bieten: Sie müssen keine Software installieren, schlagen Übersetzungen für bereits übersetzten Text vor usw.

@SlySven Ich habe das gelesen, deshalb habe ich gesagt, was ich gesagt habe. Es liest sich so, als ob es nicht vollständig unterstützt oder ein nachträglicher Gedanke wäre, weshalb ich es angeblich hinzugefügt habe (ich habe es nie getestet).

@vadi2 Die von mir erwähnten Produkte sind webbasierte Plattformen. Sie müssen jedoch weiterhin qt linguist verwenden, um die Ausgabe dieser Plattformen für das Qt-Übersetzungsframework nutzbar zu machen. Was uns auch an die unterstützten Formate TS files und XLIFF bindet.

Ich habe mit Linguist gespielt und die Benutzeroberfläche ist, soweit ich das beurteilen kann, ziemlich gut (ich bin ein Fan :heart_eyes:), sie repliziert UI-Dialoge {und zeigt den Quellcode, aus dem die Textzeichenfolge für C++ stammt, das aus QStrings }, damit Sie eine gute Vorstellung davon haben, wie sie in den verschiedenen Sprachen aussehen und gleichzeitig an mehreren Übersetzungen arbeiten können. Ich hoffe nur, dass Qt den Inhalt der TS-Dateien nicht unnötig neu anordnet, um das Git-Rauschen niedrig zu halten, wenn eine Datei von einem Mitwirkenden aktualisiert wird - anders als beispielsweise QGridLayouts in .ui-Dateien. * seufz *

Was die Notwendigkeit angeht, Qt Linguist zu verwenden - ich denke, da wir Qt-Bibliotheken im Allgemeinen verwenden, werden wir uns wahrscheinlich dazu verpflichten (wie bei _Schwein_ eher als _Hühnchen_-Engagement in einem _Speck-und-Ei-Sarnie_), abgesehen davon, dass wir nativ gettext wäre _härter_, glaube ich.

Klingt so, als ob ich daran interessiert wäre, Qt Linguist dann in etwas Webbasiertes exportieren zu sehen, mit der Option für die Leute, ihre Übersetzungen in Echtzeit zu installieren und in der Vorschau anzuzeigen, wenn sie möchten. Ich werde mir die Dienste ansehen , die Sie haben , sie sehen gut aus.

Ich hatte auch Transifex im Kopf, aber das scheint nicht mehr so ​​gut zu laufen.

Eine weitere Web-Übersetzungsplattform: https://hosted.weblate.org/projects/tilix/translations/

So handhabt das Mozilla-Projekt Lokalisierung und Übersetzung: https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Quick_start_guide/Translation_phase

Ein weiterer ausführlicher Blick auf mehrere Alternativen und den Prozess im Allgemeinen in dieser Masterarbeit zum Thema „Übersetzungen in libre software“: https://larjona.wordpress.com/translations-in-libre-software/

Danke @Kebap , ich habe das von dir verlinkte Papier gelesen. Ich interessiere mich für Weblate und Transifex - werde sie mir anschauen.

Ich möchte, dass dies die niedrigstmögliche Eintrittsbarriere hat und die Desktop-basierte Übersetzung ausschließt, bei der die Person Software herunterladen und installieren und dann nach den richtigen Dateien suchen muss, bevor sie mit der Arbeit beginnen kann.

Weblate scheint nett und quelloffen zu sein, aber ihre gehostete Version ist gerade auch nicht mehr verfügbar - und alle gehosteten Übersetzungen wie für das Tilix-Projekt. Nicht gut. Ich bin auch vorsichtig, weitere Dinge auf unserem Server zu hosten, da er bereits am Limit läuft.

Werde die Transifex-Demo ausprobieren. Sie unterstützen Open Source und scheinen ein viel größerer Shop zu sein, der im Gegensatz zu Weblate bisher weniger wahrscheinlich untergeht.

Wenn die Weblates Git-Integration tatsächlich funktioniert, ist es jedoch viel besser zu verwenden, da sie neuen Quelltext von Git _sollte_ automatisch aktualisieren und möglicherweise zurückschreiben. Transifex hingegen verlangt von mir, dass ich die zu übersetzenden Dateien manuell hochlade.

Während Transifex .ts-Dateien nativ unterstützt, scheint es beim Hochladen zu ersticken. Die Verwendung von ts2po und das Hochladen von .po Dateien funktionierte jedoch.

Es sieht so aus, als ob Sie mit etwas Middleware automatische Zwei-Wege-Updates zwischen Transifex und Github durchführen können: https://docs.transifex.com/integrations/github-txgh

Ich konnte ein .po mit intakter Übersetzung von Transifex herunterladen, aber po2ts erstickt an der Datei mit einem Python-Kodierungsfehler:

po2ts: WARNING: Error processing: input ./for_use_mudlet_rupo_1_ru.po, output ./for_use_mudlet_rupo_1_ru.ts, template None: 'ascii' codec can't encode characters in position 1994-1999: ordinal not in range(128)

Ich lasse das Transifex-Projekt unter https://www.transifex.com/mudlet/mudlet/dashboard, wenn jemand anderes es zum Übersetzen von @Kebap @keneanung möchte. Werde Weblate als nächstes ausprobieren.

Weblate ist nett - es hat eine Menge von Anmeldeoptionen von Drittanbietern, so dass der Beitritt wirklich reibungslos ist.

@vadi2 schrieb:

Ich konnte eine .po mit intakter Übersetzung von Transifex herunterladen, aber po2ts erstickt die Datei mit einem Python-Kodierungsfehler:

Ich glaube, ich habe irgendwo gelesen, dass ihre Version von po2ts nur mit einer alten Spezifikation der .ts Datei funktioniert und eine Aktualisierung benötigt (am Ende denke ich) - ich stelle fest, dass sie aus dem Translation Toolkit stammt von Übersetze den Quellcode von House mixxx internationalization page .

Tatsächlich hört sich dieser "Encoding"-Fehler so an, als würde er versuchen, eine .ts Datei zu erstellen, in der die Codierung ASCII und NICHT UTF-8 ist. das ist kein ASCII...

Diese Seite wurde zuletzt vor vier Jahren aktualisiert! Der Prozess für Entwickler ist abgeschlossen
Datum, denke ich. Das ist eine ziemlich beeindruckende Übersetzungsdokumentation
obwohl!

Am Di, 19.09.2017, 18:18 Uhr schrieb Stephen Lyons [email protected] :

@vadi2 schrieb:

Ich konnte eine .po mit intakter Übersetzung von Transifex herunterladen,
aber po2ts verschluckt sich an der Datei mit einem Python-Codierungsfehler:

Ich glaube, ich habe irgendwo gelesen, dass ihre Version von po2ts nur mit einem alten funktioniert
Spezifikation der .ts-Datei und erforderliche Aktualisierung (am Ende denke ich) - I
Beachten Sie, dass es aus dem Translation Toolkit stammt
http://toolkit.translatehouse.org/ von Translate House Github source
Code https://github.com/translate/translate und die neueste Version ist
2.2.5 (ich weiß nicht, was sie verwenden) zum Zeitpunkt des Schreibens. Ein gefunden
Webseite aus einem anderen Projekt (nicht sicher, ob sie auf GitHub basiert, aber die
Der Gesamtprozess schien für sie die Art von Dingen zu sein, die wir tun müssen: mixxx
Internationalisierungsseite
https://mixxx.org/wiki/doku.php/internationalization .


Sie erhalten dies, weil Sie zugewiesen wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Mudlet/Mudlet/issues/856#issuecomment-330592819 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAGxjEdeBPs-7fDkUwfoLjUt48eJJhl0ks5sj-lagaJpZM4M3_u1
.

Weblate scheint nicht in einer guten Position zu sein. Ich habe noch keine Antwort für meine gehostete Anwendung erhalten, und das Projekt bekommt nicht viel von Updates. Zurück zu Transifex.

Tipps zum Einrichten von Transifex mit Qt: https://forum.qt.io/topic/36750/qt5-ts-files-and-transifex-continuous-translation-localization

https://bugreports.qt.io/browse/QTBUG-1136 :

Schließlich ist Linguist im Wesentlichen auf Lebenserhaltung angewiesen - wir haben den Boden an ISVs abgetreten, die sich auf diesen Bereich spezialisiert haben.

Qt Linguist ist eine Sackgassentechnologie - es wird keine Funktionen mehr bekommen, daher müssen wir hier eine webbasierte Plattform verwenden.

Ich werde versuchen, Transifex-Übersetzungen zum Laufen zu bringen, sobald #1334 verfügbar ist.

Um nur zu wiederholen, was ich in Kebaps Querverweis erwähnt habe, dass .ts Dateien umgehen und haben auch eine Github-Integration – die Pseudolokalisierungsfunktion sollte auch helfen uns, Probleme in der GUI zu vermeiden, weil wir den Text nicht richtig strukturiert haben ( denke ich ) und wird uns auf jeden Fall helfen, genügend Spielraum für Sprachen mit Strings länger als en-US ...

CrowdIn sieht schön - mal sehen , wie es zu Transifex vergleicht, ich habe ein Testprojekt stand hier .

@SlySven, dass Code-Mangling, um HTML für Übersetzer schöner zu machen, verfrüht war - Transifex zum Beispiel behandelt HTML-Markup bereits wirklich gut:

peek 2018-05-18 13-36

Ich habe es herausgefunden - Crowdin hat diese Option auch. Wählen Sie in den Editor-Tags-Einstellungen einfach "ausblenden":

selection_143

Dies bedeutet, dass wir die Code- Mangelung, die durchgeführt hat, nicht mehr durchführen müssen - wir können HTML

Ich freue mich über den Vorschlag von @SlySven , @Kebap , @keneanung , @SlySven deine

Sobald wir uns einig sind, werde ich das Projekt bei crowdin auffrischen, damit es offiziell ist, eine Open-Source-Lizenz beantragen und wir beginnen, die Übersetzer zu informieren.

Hallo,

Ich bin ein Teil des Crowdin-Teams und helfe bei Bedarf gerne beim weiteren Setup! Bei Fragen könnt ihr mich gerne erwähnen

Mit Crowdin komme ich auch gut klar. Die Benutzeroberfläche war zunächst verwirrend, aber ich bin sicher, wir (ich) werden uns daran gewöhnen.

Ich gebe zu, dass ich mir den Transifex nicht genau angeschaut habe, da ich ihn in Gedanken ausgeschaltet habe, da ich verstanden habe, dass er das aktuelle Qt .ts Format nicht gut / direkt verarbeitet - hat sich das geändert oder lag ich falsch? in diesem Glauben?

Eine Sache von Crowdin, die ich in den letzten Git-Commits sehe, ist, dass Sie mehrere .ts Dateien hochgeladen haben, die lokal für eine bestimmte Sprache konfiguriert wurden. Sie haben es jetzt irgendwie behoben, indem Sie nur einer einzigen Datei eine mudlet_en.ts Datei gesendet haben, aber das scheint mir immer noch nicht ganz richtig zu sein. Vielleicht möchten Sie die TRANSLATIONS = Zeilen in der mudlet.pro Datei entfernen oder auskommentieren und ein Shell-Skript haben, das ausgeführt wird (in der Basis des Quellcodes):

lupdate -recursive ./src/ -ts ./translations/mudlet.ts

um eine einzelne, nicht sprachspezifische Datei zu generieren, die in den Crowdin-Übersetzungsprozess übergeht und diese dazu bringt, die gewünschten mudlet_xx_YY.ts Dateien zu erzeugen (ich habe bereits eine Einstellung in Crowdin geändert, um die _xx_YY anzugeben _xx Sprachsuffix gesetzt zu sein schien). Das führt immer noch zu einer Reihe von Dateien, die dann zurück in das gleiche Verzeichnis kopiert werden müssen, bereit für lrelease .

Übrigens, es ist hilfreich, die einfache Datei ohne Suffix zu belassen, da dies bedeutet, dass Interessenten für Minderheitensprachen sie kopieren und umbenennen können, um privat zu arbeiten, wenn sie dies mit dem bereitgestellten Qt Linguist für eine andere, nicht abgedeckte Sprache wünschen. {Vielleicht ein Piraten zum Beispiel für den 19. September!!!}

Ich denke, die Schritte zur HTML-Anti-Obfustication, die ich unternommen habe, scheinen etwas weniger notwendig geworden zu sein, da das Qt Designer-Plugin in den letzten paar Qt-Versionen ein wenig weniger darauf bedacht zu sein scheint, den HTML-Code zu verstümmeln. Ich bin noch nicht ganz davon überzeugt, dass es die Dinge nicht durcheinander bringen und ändern wird, indem es beispielsweise die Verwendung der bestimmten Schriftarten erzwingt, die die letzte Person, die sie bearbeitet hat, in ihren Systemen hat, anstatt sie generisch zu belassen kann auf allen Plattformen arbeiten. Ich werde es mir noch einmal anschauen und hier berichten, weil es sich darauf auswirkt, wie wir solchen HTML-Code in unserer Arbeit aufzeichnen.

Ich gebe zu, dass ich mir den Transifex nicht genau angeschaut habe, da ich ihn in Gedanken ausgeschaltet habe, da ich verstanden habe, dass er das aktuelle Qt .ts-Format nicht gut / direkt verarbeitet - hat sich das geändert oder lag ich in dieser Ansicht falsch?

Ich war es auch, es scheint sich geändert zu haben: https://docs.transifex.com/formats/qt-ts

Ich habe nicht vor, das Qt-Designer-Plugin zu verwenden, daher ist jegliches Manglen nicht relevant - crowdin handhabt die Übersetzungen alleine ziemlich gut, und das HTML-Rendering mit dem "Hide" -Stil ist tolerierbar.

Oh, es tut es immer noch - Tabellen und eine DTD einzufügen - also, was für Menschen einfacher zu lesen und zu parsen ist, dies:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'FreeSans'; font-size:9pt; font-weight:400; font-style:normal;">
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-size:large; font-weight:600;">Welcome to Mudlet!</span></p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Click on one of the MUDs on the list to play.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">To play a game not in the list, click on <img src=":/icons/list-add_small.png" /><span style=" color:#555753;">New</span>, fill in the <span style=" font-style:italic;">Profile Name</span>, <span style=" font-style:italic;">Server address</span>, and <span style=" font-style:italic;">Port</span> fields in the <span style=" font-style:italic;">Required</span> area.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">After that, click <img src=":/icons/dialog-ok-apply_small.png" /><span style=" color:#555753;">Connect</span> to play.</p>
<p style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Have fun!</p>
<p align="right" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">The Mudlet Team <img src=":/icons/mudlet_main_16px.png" /></p></body></html>

oder dies, was für uns dasselbe tut:

<html><head/><body><center><big><b>Welcome to Mudlet!</b></big></center></p>
<p><center>Click on one of the MUDs on the list to play.<center></p>
<p><center>To play a game not in the list, click on <img src=":/icons/list-add_small.png"/> <span style="color:#555753;">New</span>, fill in the <i>Profile Name</i>, <i>Server address</i>, and <i>Port</i> fields in the <i>Required</i> area.<center></p>
<p><center>After that, click <img src=":/icons/dialog-ok-apply_small.png"/> <span style=" color:#555753;">Connect</span> to play.</center></p>
<p>Have fun!</p>
<p align="right">The Mudlet Team <img src=":/icons/mudlet_main_16px.png"/></p></body></html>

Technisch gesehen ist dies alles Qt-Rich-Text, der nur eine Teilmenge von HTML ist (warum also die Einbeziehung der strengen HTML 4.0-DTD erzwingen?)

Auch wenn < und > hier anstelle von &lt; und &gt; in der Rohdatei angezeigt werden, die die Übersetzer sehen werden, denke ich, dass es klar ist, was passieren wird einfacher zu handhaben sein, wenn kein HTML/Qt-Rich-Text-Anzeige-Widget vorhanden ist...

Ich glaube, ich habe irgendwo gelesen, dass CJK-Sprachen wirklich keine fetten oder kursiven Schrifteffekte verwenden sollten (stattdessen denke ich, dass sie das Äquivalent eines Punktakzents an einer Kante der Glyphe verwenden) - in diesen Fällen könnte also das Markup involviert sein der Übersetzungsprozess...

Das Ausführen von Shell-Skripten ist nicht portabel (für Windows), daher würde ich das lieber nicht tun. Die aktuelle mudlet_en.ts Datei scheint gut zu funktionieren?

Es ist Freitag, also lassen Sie uns in den nächsten Tagen zu einer Schlussfolgerung kommen, damit wir mit den nächsten Schritten beginnen können, die meiner Meinung nach lauten würden:

1) Prozess für Übersetzer, um verwirrende Zeichenfolgen zu melden - wenn ein Übersetzer sie nicht versteht, besteht die Möglichkeit, dass unsere Benutzer dies auch nicht verstehen
2) eigentlicher Übersetzungsprozess und wie würde er mit unserem Workflow funktionieren

Ich würde empfehlen, zuerst mehr über die Details der benötigten Prozesse nachzudenken und erst dann zu entscheiden, welches Tool am besten zu ihnen passt.

Soweit ich das im Moment sehen kann, haben wir ein paar verschiedene Haupttextquellen:

  • Mudlet-Client selbst
  • Mudlet-Website
  • Mudlet-Wiki
  • "andere" Spontantexte müssen manuell eingefügt werden

Dann sind die Prozesse für alle ziemlich gleich, müssen jedoch separat überprüft werden:

  • Finden Sie heraus, wie Sie veraltete Texte von relevanten aktuellen Texten unterscheiden können, die übersetzt werden müssen.
  • Holen Sie sich Texte aus Quellen (siehe oben). Lässt sich das mit jedem Tool automatisieren? Wer soll verantwortlich sein?
  • Übertragen Sie Texte in das Übersetzungstool.
  • Übersetzung im Tool (ok das ist zu erwarten, braucht aber auch eine gute Schnittstelle und Workflows)
  • Übersetzer melden verwirrende Zeichenfolgen an das Mudlet-Team mit Informationen, wie sie angepasst werden müssen.
  • Das Mudlet-Team aktualisiert den Text in der Quelle. Entweder aufgrund von Berichten oder aufgrund der natürlichen Entwicklung.
  • Aktualisierte Texte aus der Quelle benötigen Aktualisierungen im Übersetzungstool. Exportieren und erneut importieren, plus diff.
  • Übersetzte Texte werden fertig. Exportieren Sie sie aus dem Übersetzungstool. Wieder automatisieren?
  • Importieren Sie übersetzten Text in die Quelle.
  • Anzeige der Übersetzungen in der Quelle. Hier benötigen wir in jeder Quelle eine Art Sprachumschalter.

Mir sind einige Plugins für Wordpress und Mediawiki aufgefallen, sowie die Integration in Crowdin und Transifex, hatte aber nicht viel Zeit, das alles genauer zu recherchieren.

Ich würde mir einen möglichst automatisierten Prozess für alle oben genannten Schritte wünschen und das Tool auswählen, das am besten unterstützt wird.

Soweit Quellcode/Dialog(Formulare) gehen:

  • Finden Sie heraus, wie Sie veraltete Texte von relevanten aktuellen Texten unterscheiden können, die übersetzt werden müssen.
  • Holen Sie sich Texte aus Quellen (siehe oben). Lässt sich das mit jedem Tool automatisieren? Wer soll verantwortlich sein?

    • Beides geschieht mit dem Befehl lupdate , der Quelltexte aus dem Quellcode extrahiert und deren Datensätze in der - meiner Meinung nach sprachneutralen Datei mudlet.ts (der Das aktuelle mudlet_en.ts signalisiert einigen Parteien, dass es speziell englischsprachige Übersetzungen bereithält - wobei - wie wir es als Quellcode verwenden werden ==> Crowdin-Datumsübertragungsmedium es für alle außer den englischen (Amerikanischen ) Fall. Wenn nicht mit der Option --no-obsolete aufgerufen, dann werden vorhandene, aber jetzt verschwundene Strings nicht entfernt - was wir zumindest während der Entwicklungsphase wollen. Der Grund, warum ich vorschlage, einen separaten für die zu generieren en-US-Gebietsschema, weil es ein sehr kurzes sein wird, das nur Zeichenfolgen für den Plural enthält, dh an Stellen, an denen wir Quellzeichenfolgen haben würden, wie z "Löschen von 2 Zimmern" verwendet.

  • Übertragen Sie Texte in das Übersetzungstool.

    • Der Prozess der Aktualisierung des Entwicklungszweigs sollte dazu führen, dass das oben Genannte passiert und die aktualisierten .ts aus (ich schlage vor) dem Linux-CI-Build hochgeladen werden (da es für uns am einfachsten ist, dafür ein Skript zu erstellen)

  • Übersetzung im Tool (ok das ist zu erwarten, braucht aber auch eine gute Schnittstelle und Workflows)
  • Übersetzer melden verwirrende Zeichenfolgen an das Mudlet-Team mit Informationen, wie sie angepasst werden müssen.

    • Es sieht so aus, als ob Crowdin jedem erlaubt, einen Kommentar zu einer beliebigen Quellzeichenfolge abzugeben oder ein Problem zu melden, die zumindest für den Manager sichtbar ist (aber möglicherweise für mehr Parteien offen ist).

  • Das Mudlet-Team aktualisiert den Text in der Quelle. Entweder aufgrund von Berichten oder aufgrund der natürlichen Entwicklung.

    • Einschließlich Stellen, an denen der Quelltext verwirrend oder in der erwarteten en_US-Form falsch geschrieben ist - zB habe ich möglicherweise die Lizenz verwendet (en-GB Substantiv , vgl. Lizenz als en-GB Verb ), aber es ist immer lizenz in en-US für beide Formen.

  • Aktualisierte Texte aus der Quelle benötigen Aktualisierungen im Übersetzungstool. Exportieren und erneut importieren, plus diff.

    • Führen Sie lupdate - aber dies sollte natürlich über CI-Skripte bei Aktualisierungen des Zweigs "Entwicklung" passieren

  • Übersetzte Texte werden fertig. Exportieren Sie sie aus dem Übersetzungstool. Wieder automatisieren?

    • Einer von uns kann Übersetzungen als vollständigen Satz von mudlet_xx_YY.ts Dateien manuell von Crowdin "herunterladen" und sie in das /translations -Verzeichnis übertragen. Denken Sie daran, dass diese Dateien nicht von lupdate aktualisiert werden. Pluralformen mudlet_en_US.ts - stattdessen werden sie bei Crowdin aus der Datei mudlet.ts generiert.

  • Importieren Sie übersetzten Text in die Quelle.

    • Nicht unbedingt erforderlich, die Übersetzungstexte werden von der Anwendung nicht aus den .ts Dateien gelesen. Stattdessen liest die Mudlet-Anwendung, sobald ich den Code überarbeitet und veröffentlicht habe, die Übersetzungen zur Laufzeit, indem sie die ausgewählte mudlet_xx_YY.qm Binärdatei lädt (zusammen mit der entsprechenden Qt-Datei - die wir bereits kennen) mit den Installer-Versionen verteilen!) Also stelle ich mir zunächst vor, dass einer von uns lrelease ausführen wird, um die .ts Dateien in die passenden .qm Dateien zu konvertieren und sie in das Git-Repository zu übertragen als Gut. Schließlich hat Vadim vorgeschlagen, dass wir die Release-Versionen mit einem Satz von .qm Dateien als Ressourcendatei liefern werden. Dies ist für Installer-Versionen geeignet, aber Linux-Paketierer erwarten stattdessen, dass sie sie in einem schreibgeschützten /usr/share/mudlet/translations speichern (neben den externen Mudlet-lua-Dateien). Ich habe einen Prototypcode, der es ermöglicht, beide Arrangements zu handhaben, aber indem der Benutzer Übersetzungsdateien von woanders laden kann (möglicherweise aus dem /translations Verzeichnis im Quellcode), würde dies die eigenständige Entwicklung von Übersetzungen ermöglichen für andere Minderheitensprachen von interessierten Parteien mit dem ursprünglichen Qt-Tool Linguist - es würde Entwicklern auch ermöglichen, an privaten/Testfällen zu arbeiten.

  • Anzeige der Übersetzungen in der Quelle. Hier benötigen wir in jeder Quelle eine Art Sprachumschalter.

    • Aus Experimenten ist die Verwendung der QLangaugeEvent komplexer als wir brauchen, da sie jedes Mal ausgelöst wird, wenn QQTranslator::load(...) aufgerufen wird. Ich habe festgestellt, dass es einfacher ist, die mudlet Klasse emit a (void) signal_translatorChangeCompleted(const QString&, const QString&) wo die Argumente der aktuellen und vorherigen xx_YY Codes (language_COUNTRY/REGION) weitgehend ungenutzt sind, mit Ausnahme von IIRC Host das ein lua-Ereignis für das Skript generiert /package-Ereignishandler, mit denen gearbeitet werden soll. Dieses Signal wird an jede Klasse mit persistenten GUI-Texten an ein slot_guiLanguageChange() gesendet, wo es die erforderlichen retranslateUi(this) aufruft, die in jeder Klasse definiert sind, die auch setupUi(this) vorausgesetzt, Sie haben die Option in Qt IDE korrekt (ich weiß nicht, wie das funktioniert, wenn qmake direkt verwendet wird):

      qt_options

      Dieser Aufruf ändert die Übersetzungen für jeden übersetzbaren String in den Formularen/Dialogen und dann müssen wir alle GUI-Texte, die wir zur Laufzeit erstellen, neu generieren, wobei wir berücksichtigen, welche Bedingungen auch immer dazu geführt haben könnten, dass verschiedene Texte zusammengestellt wurden. Das ist gar nicht so schlimm, wie es sich anhört, da wir nur den persistenten - dh für lange Zeit bestehenden - String ändern müssen, da die transienten Texte automatisch die neue Übersetzung verwenden, wenn tr(...) verwendet wird, um sie zu erstellen.

Dies ist nicht alles, was ich zu diesem Thema habe, aber ich kann sehen, wie die meisten Schritte für Anwendungs-GUI-Texte ablaufen sollten ...

Danke für diese Details, SlySven! Mir scheint, hast du das vielleicht schon mal gemacht? Für eine andere Anwendung? Mit Corwdin? Das würde die Übersetzung der Mudlet-Anwendung selbst viel einfacher machen.

Auf der anderen Seite haben wir immer noch die gleichen Fragen für die anderen Textquellen im Mudlet-Universum, wie Wiki-Dokumentation, Mudlet-Website und zusätzliche Texte, die möglicherweise etwas manuell eingefügt werden müssen, wie in meinem letzten Beitrag oben erklärt.

Ich habe die obige Antwort nicht vollständig durchgegangen, aber Crowdin verfügt über eine Github-Integration, die nicht berücksichtigt wird - https://github.com/Mudlet/Mudlet/pull/1692 ist eine automatisch generierte PR, die wir nicht tun müssen jedes manuelle Hoch- oder Herunterladen; einfach die PRs zusammenführen. Somit wird der Vorgang um einiges einfacher als beschrieben!

Die Crowdin-Testversion für Jungs läuft in 4 Tagen ab, also brauche ich ein Ja/Nein dazu - wir scheinen bisher damit zufrieden zu sein

Es gab ein Juhu von mir!

Hallo! ;)

Ich habe https://crowdin.com/ versucht … zum Übersetzen ist es in Ordnung, ich weiß nicht, ob es gut ist für schnelles Feedback, Anfragen usw.

Was ist mit dem Kommentarbereich in crowdin?

Hallo @Joker-ITA,

Es gibt tatsächlich mehrere Möglichkeiten, wie Sie zusätzlichen Kontext für Übersetzer hinzufügen können:

1) Klicken Sie im Editor unter der Zeichenfolge auf "Kontext bearbeiten", um den Übersetzern weitere Informationen bereitzustellen.
2) Sie können im Editor für jede beliebige Zeichenfolge einen Kommentar hinterlassen (im rechten Bereich geben Sie Ihren Kommentar ein);
3) Fügen Sie Kontext für einen beliebigen String über die Projekteinstellungen -> Registerkarte Strings hinzu;
4) Ich wette, Sie haben einige spezifische Begriffe, die normale Übersetzer möglicherweise nicht verstehen, daher ist es sinnvoll, ein Glossar zu erstellen und es auf Crowdin hochzuladen. Mehr Infos . Es kann sogar eine Excel-Tabelle mit 2 Spalten sein: Begriff & Beschreibung;
5) Wenn Sie Kommentare in Dateien haben (zB Android XML, iOS-Strings, .properties, .yml, Google Chrome JSON), werden diese automatisch zusammen mit der Datei importiert;
6) Sie können den Screenshot zu Crowdin hochladen und eine beliebige Zeichenfolge darauf taggen: https://support.crowdin.com/adding-screenshots/
7) Wenn wir über Webapp l10n sprechen, ist es sinnvoll, unsere In-Context- Funktion auszuprobieren, damit Übersetzer direkt auf Ihrer Website übersetzen können.

Es sind nur die wichtigsten Möglichkeiten, wie Sie Texte für die Übersetzung kontextualisieren können 😄

@Kebap schrieb:

Danke für diese Details, SlySven! Mir scheint, hast du das vielleicht schon mal gemacht? Für eine andere Anwendung? Mit Corwdin? Das würde die Übersetzung der Mudlet-Anwendung selbst viel einfacher machen.

Nur manuell mit den eigenen Tools von Qt (ich habe in den letzten Jahren einige Wochen in Südfrankreich verbracht, um die Details auszuarbeiten). Wir werden weiterhin zwei davon verwenden - lupdate & lrelease - aber wir ersetzen Qt Linguist (das Werkzeug, das die Übersetzungen zu den Quelltexten hinzufügt, die in einer Reihe von .ts Dateien, die von lupdate für jede Übersetzung generiert werden, bevor lrelease sie in die sprach-/standortspezifischen mudlet_xx_YY.qm Dateien umwandelt, die benötigt werden – wiederum eine pro Sprache/Standort-Übersetzung angeboten) mit Crowdin, das eine einzelne mudlet.ts -Datei nimmt und stattdessen die mudlet_xx_YY.ts Dateien generiert.

Ein wichtiger Unterschied zwischen der Verwendung von linguist und dem, was wir mit Crowid tun werden, besteht darin, dass wir ohne Folgendes davonkommen können:

TRANSLATIONS =

Zeile in der Projektdatei für Crowd.

Eigentlich denke ich, dass wir zwei Dateien brauchen werden - mudlet.ts für alle Gebietsschemas und die den Crowdin-Prozess durchlaufen und mudlet_en_US.ts die mit der Option -pluralonly extrahiert werden und nur haben werden ein paar Übersetzungen , um Nachrichten wie tr("deleted %n room(s)", "", roomCount) in "deleted 1 room" oder "deleted 2 rooms" umzuwandeln, abhängig vom Wert von roomCount und können wahrscheinlich von Ihnen wirklich gemacht werden...

Super - wir gehen mit Crowdin :)

Ich werde den Dateinamen wie von @SlySven vorgeschlagen anpassen und das Projekt in Crowdin richtig einrichten, damit die Leute mit der Übersetzung beginnen können. Alle vorhandenen Testübersetzungen, die wir erstellt haben, werden im Transaktionsspeicher gespeichert, sodass sie ganz einfach erneut angewendet werden können.

Beantwortung der Fragen von @Kebap unter Berücksichtigung der Antwort von @SlySven :

  • Finden Sie heraus, wie Sie veraltete Texte von relevanten aktuellen Texten unterscheiden können, die übersetzt werden müssen.

    • lupdate Tool macht dies

  • Holen Sie sich Texte aus Quellen (siehe oben). Lässt sich das mit jedem Tool automatisieren? Wer soll verantwortlich sein?
  • Übertragen Sie Texte in das Übersetzungstool.

    • wir führen lupdate manuell aus und verpflichten sie zu development - dieser Teil könnte täglich von Travis automatisiert werden

    • crowdin holt sie aufgrund der github-Integration automatisch ab

  • Übersetzung im Tool (ok das ist zu erwarten, braucht aber auch eine gute Schnittstelle und Workflows)

    • Crowdins Übersetzungsschnittstelle

  • Übersetzer melden verwirrende Zeichenfolgen an das Mudlet-Team mit Informationen, wie sie angepasst werden müssen.

    • schreibe ein Problem in Crowdin auf

  • Das Mudlet-Team aktualisiert den Text in der Quelle. Entweder aufgrund von Berichten oder aufgrund der natürlichen Entwicklung.
  • Aktualisierte Texte aus der Quelle benötigen Aktualisierungen im Übersetzungstool. Exportieren und erneut importieren, plus diff.

    • Crowdin hebt es auf

  • Übersetzte Texte werden fertig. Exportieren Sie sie aus dem Übersetzungstool. Wieder automatisieren?
  • Importieren Sie übersetzten Text in die Quelle.
  • Anzeige der Übersetzungen in der Quelle. Hier benötigen wir in jeder Quelle eine Art Sprachumschalter.

    • @SlySven wird hier zaubern :)

Was ist für eine separate Übersetzungsdatei mit nur den Pluralen erforderlich?

Übersetzungsanweisungen sind verfügbar unter https://wiki.mudlet.org/w/Translating_Mudlet

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen