Übersetzungsprojekte¶
Übersetzungsorganisation¶
Weblate organisiert die übersetzbaren VCS-Inhalte von Projekten/Komponenten in einer baumartigen Struktur. Sie können Komponenten innerhalb eines Projekts zusätzlich über Kategorien organisieren.
Das unterste Objekt ist die Projektkonfiguration, die alle zusammengehörenden Übersetzungen enthalten soll (z. B. Übersetzung einer Anwendung in mehreren Versionen und/oder Begleitdokumentation).
Die mittlere Ebene wird optional durch die Kategorie erstellt. Die Kategorien können verschachtelt werden, um eine komplexere Struktur zu erreichen.
Auf der darüber liegenden Ebene die Komponentenkonfiguration, welche die eigentlich zu übersetzende Komponente ist, definieren Sie das zu verwendende VCS-Repository und die Maske der zu übersetzenden Dateien.
Oberhalb der Komponentenkonfiguration gibt es individuelle Übersetzungen, die von Weblate automatisch behandelt werden, wenn Übersetzungsdateien (die mit der in der Komponentenkonfiguration definierten Dateimaske übereinstimmen) im VCS-Repository erscheinen.
Weblate unterstützt eine breite Palette von Übersetzungsformaten (sowohl zweisprachige als auch einsprachige), die vom Translate Toolkit unterstützt werden, siehe Unterstützte Dateiformate.
Bemerkung
Sie können geklonte VCS-Repositorys mit Weblate-interne URLs freigeben. Die Verwendung dieser Funktion wird dringend empfohlen, wenn viele Komponenten dasselbe VCS gemeinsam nutzen. Sie verbessert die Leistung und verringert den benötigten Speicherplatz.
Übersetzungsprojekte und Komponenten hinzufügen¶
Je nach Ihren Berechtigungen können Sie neue Übersetzungsprojekte und Komponenten erstellen. Für Benutzer mit der Berechtigung Neue Projekte hinzufügen ist dies immer erlaubt, und wenn Ihre Instanz ein Abrechnungsmodell verwendet (wie z. B. https://hosted.weblate.org/ siehe Abrechnung), können Sie diese auch auf der Grundlage Ihrer Pläne von dem Benutzerkonto erstellen, das die Abrechnung verwaltet.
Hinweis
Um jedem Benutzer die Berechtigung zu erteilen, neue Projekte zu erstellen, legen Sie Automatische Teamzuweisungen für das Projektersteller-Team an.
Sie können Ihr aktuelles Abrechnungsmodell auf einer separaten Seite einsehen:
Die Projekterstellung kann von dort aus oder über das Menü in der Navigationsleiste eingeleitet werden, wobei die grundlegenden Informationen über das Übersetzungsprojekt eingegeben werden müssen, um es vollständig zu ergänzen:
Nach der Erstellung des Projekts werden Sie direkt zur Projektseite weitergeleitet:
Die Erstellung einer neuen Übersetzungskomponente kann dort mit einem einzigen Klick gestartet werden. Der Prozess der Komponentenerstellung ist mehrstufig und erkennt die meisten Übersetzungsparameter automatisch. Es gibt mehrere Ansätze zum Erstellen einer Komponente:
- Von der Versionsverwaltung
Erzeugt eine Komponente aus einem Remote-VCS-Repository.
- Aus vorhandener Komponente
Erzeugt eine zusätzliche Komponente zu einer bereits vorhandenen durch Auswahl verschiedener Dateien.
- Zusätzlicher Branch
Erzeugt eine zusätzliche Komponente zu einer bereits vorhandenen, lediglich für einen anderen Branch.
- Übersetzungsdateien hochladen
Übersetzungsdateien in Weblate hochladen, falls es keine Versionsverwaltung gibt oder diese nicht in Weblate integriert werden soll. Die Inhalte können später über die Weboberfläche oder Weblates REST-API aktualisiert werden.
- Dokument übersetzen
Ein einzelnes Dokument oder eine Übersetzungsdatei hochladen und diese übersetzen.
- Bei Null anfangen
Ein leeres Übersetzungsprojekt erstellen und Zeichenketten manuell hinzufügen.
Sobald Sie über vorhandene Übersetzungskomponenten verfügen, können Sie auch leicht neue Komponenten für zusätzliche Dateien oder Branches hinzufügen, indem Sie dasselbe Repository verwenden.
Zunächst müssen Sie den Namen und Speicherort des Repositorys eingeben:
Auf der nächsten Seite wird Ihnen eine Liste der gefundenen übersetzbaren Ressourcen angezeigt:
In einem letzten Schritt überprüfen Sie die Informationen zur Übersetzungskomponente und füllen optionale Details aus:
Projektkonfiguration¶
Erstellen Sie ein Übersetzungsprojekt und fügen Sie darin eine neue Komponente für die Übersetzung ein. Das Projekt ist wie ein Regal, in dem echte Übersetzungen gestapelt werden. Alle Komponenten im selben Projekt teilen sich Vorschläge und ihr Wörterbuch; die Übersetzungen werden auch automatisch durch alle Komponenten in einem einzelnen Projekt weitergegeben (es sei denn, sie sind in der Komponentenkonfiguration ausgeschaltet), siehe Übersetzungsspeicher.
Siehe auch
Mit diesen grundlegenden Attributen werden die Übersetzer eines Projekts eingerichtet und informiert:
Projektname¶
Ausführlicher Projektname, der zur Anzeige des Projektnamens verwendet wird.
Siehe auch
URL-Kurzbegriff¶
Für URLs geeigneter Projektname.
Projektseite¶
URL, unter der Übersetzer weitere Informationen über das Projekt finden können.
Dieser Parameter ist obligatorisch, sofern er nicht durch WEBSITE_REQUIRED ausgeschaltet wird.
Übersetzungsanweisungen¶
Text, der den Lokalisierungsprozess im Projekt beschreibt, sowie alle anderen für Übersetzer nützlichen Informationen. Markdown kann zur Textformatierung oder zum Einfügen von Links verwendet werden.
Kopfzeile „Language-Team“ setzen¶
Ob Weblate den Language-Team-Header verwalten soll (dies ist zur Zeit nur eine GNU gettext PO (Portable Object)-Funktion).
Zugriffssteuerung¶
Die Zugriffssteuerung pro Projekt konfigurieren, siehe Projekt-Zugriffssteuerung für weitere Details.
Der Standardwert kann durch DEFAULT_ACCESS_CONTROL geändert werden.
Überprüfung aktivieren¶
Den Überprüfungsablauf für Übersetzungen aktivieren, siehe Dedizierte Prüfer.
Siehe auch
Quellenüberprüfung aktivieren¶
Den Überprüfungsablauf für Ausgangszeichenketten aktivieren, siehe Überprüfungen der Ausgangszeichenketten.
Hooks aktivieren¶
Ob nicht authentifizierte Benachrichtigungs-Hooks für dieses Repository verwendet werden sollen.
Sprachaliasnamen¶
Definieren Sie die Zuordnung von Sprachcodes beim Import von Übersetzungen in Weblate. Verwenden Sie dies, wenn die Sprachcodes in Ihren Repositorys inkonsistent sind und Sie eine konsistente Ansicht in Weblate erhalten möchten oder wenn Sie nicht standardisierte Namen für Ihre Übersetzungsdateien verwenden möchten.
Ein typischer Anwendungsfall wäre die Zuordnung von amerikanischem Englisch auf Englisch: en_US:en
Mehrere Zuordnungen sind durch Komma zu trennen: en_GB:en,en_US:en
Verwendung von Nicht-Standard-Code: ia_FOO:ia
Hinweis
Die Sprachcodes werden beim Abgleich mit den Übersetzungsdateien zugeordnet, wobei zwischen Groß-/Kleinschreibung unterschieden wird. Achten Sie also darauf, dass Sie die Sprachcodes der Ausgangssprache in der gleichen Form wie in den Dateinamen verwenden.
Komponentenkonfiguration¶
Eine Komponente ist eine Gruppierung von etwas, das übersetzt werden soll. Sie geben den Ort des VCS-Repositorys und die Dateimaske für die zu übersetzenden Dateien an, und Weblate holt sie automatisch aus diesem VCS und findet alle passenden übersetzbaren Dateien.
Siehe auch
Einige Beispiele für typische Konfigurationen finden Sie in Unterstützte Dateiformate.
Bemerkung
Es wird empfohlen, die Übersetzungskomponenten auf eine vernünftige Größe zu beschränken – teilen Sie die Übersetzung nach allem auf, was in Ihrem Fall sinnvoll ist (einzelne Anwendungen oder Erweiterungen, Buchkapitel oder Websites).
Weblate bewältigt problemlos Übersetzungen mit 10000 Zeichenketten, aber bei so großen Übersetzungskomponenten ist es schwieriger, die Arbeit aufzuteilen und unter den Übersetzern zu koordinieren.
Sollte die Sprachdefinition für eine Übersetzung fehlen, wird eine leere Definition erstellt und als „cs_CZ (erzeugt)“ bezeichnet. Sie sollten die Definition anpassen und dies an die Weblate-Autoren zurückmelden, damit die fehlenden Sprachen in die nächste Version aufgenommen werden können.
Die Komponente enthält alle wichtigen Parameter für die Arbeit mit dem VCS und für die Erstellung von Übersetzungen daraus:
Komponentenname¶
Ausführlicher Komponentenname, der zur Anzeige des Komponentennamens verwendet wird.
Komponenten-Slug¶
Für URLs geeigneter Komponentenname.
Komponenten-Projekt¶
Projektkonfiguration, zu dem die Komponente gehört.
Versionsverwaltung¶
Zu verwendendes VCS, siehe Integration der Versionsverwaltung für Details.
Siehe auch
Quellcode-Repository¶
VCS-Repository, das zum Ziehen von Änderungen verwendet wird.
Siehe auch
Siehe Zugriff auf Repositorys für weitere Details zur Angabe von URLs.
Hinweis
Dies kann entweder eine echte VCS-URL oder weblate://project/component sein, die angibt, dass das Repository mit einer anderen Komponente geteilt werden soll. Siehe Weblate-interne URLs für weitere Details.
Repository-Push-URL¶
Repository-URL, die für das Pushen verwendet wird. Das Verhalten hängt von der Versionsverwaltung ab, und dies wird in Pushen von Änderungen aus Weblate detaillierter behandelt.
Für verlinkte Repositorys wird dies nicht verwendet und es gilt die Einstellung der verlinkten Komponente.
Siehe auch
Siehe Zugriff auf Repositorys für weitere Details, wie man eine Repository-URL angibt und Pushen von Änderungen aus Weblate für weitere Details, wie man Änderungen von Weblate pusht.
Repository-Browser¶
URL des Repository-Browsers, der zur Anzeige der Quelldateien verwendet wird (Ort der verwendeten Nachrichten). Wenn leer, werden keine derartigen Links erzeugt. Es kann Auszeichnungsvorlage verwendet werden.
Verwenden Sie auf GitHub zum Beispiel etwas wie: https://github.com/WeblateOrg/hello/blob/{{branch}}/{{filename}}#L{{line}}
Falls Ihre Pfade relativ zu verschiedenen Verzeichnissen sind (Pfad enthält ..), sollten Sie das führende Verzeichnis durch den Filter parentdir entfernen (siehe Auszeichnungsvorlage): https://github.com/WeblateOrg/hello/blob/{{branch}}/{{filename|parentdir}}#L{{line}}
Exportierte Repository-URL¶
URL, unter der die von Weblate vorgenommenen Änderungen exportiert werden. Dies ist wichtig, wenn Kontinuierliche Lokalisierung nicht verwendet wird, oder wenn Änderungen manuell zusammengeführt werden müssen. Git-Exporter kann verwendet werden, um dies für Git-Repositorys zu automatisieren.
Repository-Branch¶
Welcher Branch aus dem VCS ausgecheckt werden soll und in welchem nach Übersetzungen gesucht werden soll.
Für verlinkte Repositorys wird dies nicht verwendet und es gilt die Einstellung der verlinkten Komponente.
Push-Branch¶
Branch zum Pushen von Änderungen, leer lassen, um Repository-Branch zu verwenden.
Für verlinkte Repositorys wird dies nicht verwendet und es gilt die Einstellung der verlinkten Komponente.
Bemerkung
Dies wird derzeit nur für Git, GitLab und GitHub unterstützt, für andere VCS-Integrationen wird es ignoriert.
Siehe auch
Dateimaske¶
Maske der zu übersetzenden Dateien, einschließlich Pfad. Sie sollte einen „*“ enthalten, der den Sprachcode ersetzt (siehe Sprachdefinitionen für Informationen darüber, wie dieser verarbeitet wird). Falls das Repository mehr als eine Übersetzungsdatei enthält (z. B. mehrere gettext-Domains), müssen Sie für jede dieser Dateien eine Komponente erstellen.
Zum Beispiel po/*.po oder locale/*/LC_MESSAGES/django.po.
Falls der Dateiname Sonderzeichen wie [, ] enthält, müssen diese als [[] oder []] maskiert werden.
Bildschirmfoto-Dateimaske¶
Diese Funktion ermöglicht das Erkennen und Aktualisieren von Bildschirmfotos durch die Bildschirmfoto-Dateimasken unter Verwendung von Pfaden aus dem VCS-Repository. Dies funktioniert auf Komponentenebene und erfordert die Verwendung eines Sternchens „*“ als Ersatz für den Namen der Bildschirmfoto-Datei.
Erlaubte Formate sind WebP, JPEG, PNG, APNG und GIF.
Anmerkung:
Die Dateimaske und die Bildschirmfoto-Dateimaske sind nicht zueinander zugehörig. Konfigurieren Sie sie separat.
Es ist eine manuelle Aufgabe, ein gefundenes Bildschirmfoto in einer Komponente mit einem bestimmten Übersetzungsschlüssel zu verknüpfen.
Zum Beispiel:
Nehmen wir an, Ihr VCS-Repository hat eine Struktur wie diese:
component_A
└── docs
├── image1.png
└── image2.jpg
Für component_A möchten Sie das Erkennen und Aktualisieren von PNG-Bildschirmfotos erlauben. Sie legen die Maske für die Bildschirmfoto-Datei für component_A als component_A/docs/*.png fest. Das bedeutet, dass alle PNG-Bilder unter docs in component_A gefunden und aktualisiert werden können. Wenn Sie also image1.png aktualisieren möchten, sollte das neue Bildschirmfoto, das Sie bereitstellen, image1.png heißen, mit dem bestehenden filename übereinstimmen und unter component_A/docs/ gespeichert werden.
Einsprachige Basissprachdatei¶
Basisdatei mit Zeichenkette-Definitionen für Einsprachige Komponenten.
Basisdatei bearbeiten¶
Ob die Bearbeitung von Zeichenketten in der einsprachigen Basissprachdatei erlaubt werden soll.
Zwischensprachedatei¶
Zwischensprachdatei für Einsprachige Komponenten. In den meisten Fällen handelt es sich dabei um eine von den Entwicklern bereitgestellte Übersetzungsdatei, die bei der Erstellung der eigentlichen Ausgangszeichenketten verwendet wird.
Wenn diese Option gesetzt ist, basieren die Ausgangszeichenketten auf dieser Datei, aber alle anderen Sprachen basieren auf Einsprachige Basissprachdatei. Falls die Zeichenkette nicht in die Ausgangssprache übersetzt wird, ist die Übersetzung in andere Sprachen verboten. Dies bietet Qualitäts-Gateway für die Ausgangszeichenketten.
Vorlage für neue Übersetzungen¶
Basisdatei für das Erstellen neuer Übersetzungen.
Lassen Sie dieses Feld bei den meisten monolingualen Formaten leer. Diese können in der Regel mit einer leeren Datei beginnen.
Wählen Sie
.pot-Datei mit GNU gettext PO-Dateien.Wählen Sie eine leere Datei ohne Übersetzungen, wenn Sie eine haben.
Wählen Sie Einsprachige Basissprachdatei für einsprachige Formate, die einen vollständigen Satz von Schlüsseln benötigen.
Wählen Sie Einsprachige Basissprachdatei für Dokumentübersetzungen.
Wählen Sie eine beliebige Übersetzungsdatei für andere Übersetzungen.
Die Vorlagendatei kann in den meisten Fällen dieselbe sein wie die Basisdatei.
Hinweis
In vielen einsprachigen Formaten beginnt Weblate standardmäßig mit einer leeren Datei. Verwenden Sie diese Option, wenn Sie möchten, dass bei der Erstellung einer neuen Übersetzung alle Zeichenketten mit einem leeren Wert vorhanden sind.
Dateiformat¶
Format der Übersetzungsdatei, siehe auch Unterstützte Dateiformate.
Adresse für Fehlerberichte bei Ausgangszeichenketten¶
E-Mail-Adresse, die für die Meldung von Upstream-Fehlern verwendet wird. Diese Adresse erhält auch Benachrichtigungen über Kommentare zu den Ausgangszeichenketten in Weblate.
Beim GNU gettext PO (Portable Object)-Format wird diese Adresse von Weblate auch im Report-Msgid-Bugs-To-Header der Datei gespeichert.
Weitergabe von Übersetzungen erlauben¶
Sie können die Weitergabe von Übersetzungen aus anderen Komponenten desselben Projekts an diese Komponente ausschalten. Dies hängt wirklich davon ab, was Sie übersetzen, manchmal ist es wünschenswert, eine Übersetzung mehr als einmal zu verwenden.
Es ist normalerweise eine gute Idee, diese Funktion für einsprachige Übersetzungen zu deaktivieren, es sei denn, Sie verwenden dieselben IDs für das gesamte Projekt.
Der Standardwert kann durch DEFAULT_TRANSLATION_PROPAGATION geändert werden.
Vorschläge aktivieren¶
Ob Übersetzungsvorschläge für diese Komponente angenommen werden.
Siehe auch
Über Vorschläge abstimmen¶
Schaltet die Stimmabgabe für Vorschläge ein, siehe Über Vorschläge abstimmen.
Siehe auch
Vorschläge automatisch annehmen¶
Vorschlagsabstimmungen werden automatisch angenommen, siehe Über Vorschläge abstimmen.
Siehe auch
Übersetzungsmarkierungen¶
Anpassen von Qualitätsprüfungen und anderem Verhalten von Weblate, siehe Anpassen des Verhaltens mit Markierungen.
Erzwungene Qualitätsprüfungen¶
Liste der Prüfungen, die nicht ignoriert werden können, siehe Qualitätsprüfungen erzwingen.
Bemerkung
Das Erzwingen der Prüfung aktiviert sie nicht automatisch, Sie sollten sie immer noch mit Anpassen des Verhaltens mit Markierungen in Übersetzungsmarkierungen oder Zusätzliche Informationen über Ausgangszeichenketten aktivieren.
Übersetzungslizenz¶
Lizenz der Übersetzung (muss nicht mit der Lizenz des Quellcodes übereinstimmen).
Mitwirkungsvereinbarung¶
Die Benutzervereinbarung muss genehmigt werden, bevor der Benutzer die Komponenten übersetzen kann.
Neue Übersetzung hinzufügen¶
Wie man mit Anfragen zur Erstellung neuer Sprachen umgeht. Verfügbare Optionen:
- Projektbetreuer kontaktieren
Der Benutzer kann die gewünschte Sprache auswählen und die Projektbetreuer erhalten eine Benachrichtigung darüber. Es liegt an ihnen, ob Sie die Sprache zum Repository hinzufügen.
- Auf die URL für die Übersetzungsanweisungen verweisen
Der Benutzer erhält einen Link zu einer Seite, die den Prozess des Beginns neuer Übersetzungen beschreibt. Verwenden Sie diese Seite, wenn ein formellerer Prozess gewünscht wird (z. B. die Bildung eines Teams von Personen vor dem Beginn der eigentlichen Übersetzung).
- Neue Sprachdatei erstellen
Der Benutzer kann eine Sprache auswählen, Weblate erstellt automatisch die entsprechende Datei und die Übersetzung kann beginnen.
- Hinzufügen neuer Übersetzungen deaktivieren
Es gibt keine Möglichkeit für den Benutzer, eine neue Übersetzung zu beginnen.
Hinweis
Die Projektadministratoren können neue Übersetzungen hinzufügen, auch wenn dies hier deaktiviert ist, wenn dies möglich ist (entweder Vorlage für neue Übersetzungen oder das Dateiformat unterstützt den Beginn von einer leeren Datei).
Zeichenketten verwalten¶
Added in version 4.5.
Legt fest, ob Benutzer in Weblate neue Zeichenketten hinzufügen und vorhandene entfernen dürfen. Passen Sie dies an Ihren Lokalisierungsprozess an – wie die neuen Zeichenketten eingeführt werden sollen.
Bei zweisprachigen Formaten werden die Zeichenketten in der Regel aus dem Quellcode extrahiert (z. B. mit xgettext), und das Hinzufügen neuer Zeichenketten in Weblate sollte deaktiviert werden (sie würden bei der nächsten Aktualisierung der Übersetzungsdateien verworfen werden). In Weblate können Sie Zeichenketten für jede Übersetzung verwalten, und es wird nicht erzwungen, dass die Zeichenketten in allen Übersetzungen konsistent sind.
Bei einsprachigen Formaten werden die Zeichenketten nur in der Ausgangssprache verwaltet und in den Übersetzungen automatisch hinzugefügt oder entfernt. Die Zeichenketten erscheinen in den Übersetzungsdateien, sobald sie übersetzt sind.
Hinweis
Sie können Basisdatei bearbeiten zusammen mit Zeichenketten verwalten für einsprachige Formate einschalten.
Stil des Sprachcodes¶
Anpassen des Sprachcodes, der zur Generierung des Dateinamens für von Weblate erstellte Übersetzungen verwendet wird.
Bemerkung
Weblate erkennt alle Sprachcodes beim Analysieren von Übersetzungsdateien, die folgenden Einstellungen beeinflussen nur, wie neue Dateien erstellt werden.
- Standard basierend auf dem Dateiformat
Abhängig vom Dateiformat, für die meisten davon wird POSIX verwendet.
- POSIX-Stil mit Unterstrich als Trennzeichen
Wird in der Regel von gettext und ähnlichen Tools verwendet, erzeugt Sprachcodes wie
pt_BR.- POSIX-Stil mit Unterstrich als Trennzeichen, einschließlich Ländercode
Sprachcode im POSIX-Stil einschließlich des Ländercodes, auch wenn dies nicht erforderlich ist (z. B.
cs_CZ).- POSIX-Stil mit Unterstrich als Trennzeichen, einschließlich Ländercode (Kleinbuchstaben)
Sprachcode im POSIX-Stil einschließlich des Ländercodes, auch wenn dies nicht erforderlich ist (Kleinbuchstaben) (z. B.
cs_cz).- BCP-Stil mit Bindestrich als Trennzeichen
Wird in der Regel auf Webplattformen verwendet und erzeugt Sprachcodes wie
pt-BR.- BCP-Stil mit Bindestrich als Trennzeichen, einschließlich Ländercode
Sprachcode im BCP-Stil, einschließlich des Ländercodes, auch wenn dies nicht erforderlich ist (z. B.
cs-CZ).- BCP-Stil mit Bindestrich als Trennzeichen, herkömmliche Sprachcodes
Verwendet herkömmliche Codes für die chinesische und die BCP-Schreibweise.
- BCP-Stil mit Bindestrich als Trennzeichen, Kleinbuchstaben
BCP-Schreibweise, alles in Kleinbuchstaben (zum Beispiel
cs-cz).- Apple App Store Metadaten-Stil
Stil, der zum Hochladen von Metadaten in den Apple App Store geeignet ist.
- Google Play Metadaten-Stil
Stil, der für das Hochladen von Metadaten in den Google Play Store geeignet ist.
- Android-Stil
Wird nur in Android-Apps verwendet, erzeugt Sprachcodes wie
pt-rBR.- Linux-Stil
Gebietsschemas, wie sie von Linux verwendet werden, verwenden herkömmliche Codes für die chinesische und POSIX-Notation.
Git-Strategie¶
Sie können konfigurieren, wie Aktualisierungen aus dem Upstream-Repository behandelt werden sollen. Die tatsächliche Implementierung hängt vom VCS ab, siehe Integration der Versionsverwaltung.
- Umbasieren (Rebase)
Basiert Weblate-Commits beim Aktualisieren auf das Upstream-Repository um. Dies bietet einen sauberen Verlauf ohne zusätzliche Merge Commits.
Das Umbasieren kann bei komplizierten Zusammenführungen zu Problemen führen, daher sollten Sie sorgfältig abwägen, ob Sie diese Funktion aktivieren möchten oder nicht.
Möglicherweise müssen Sie erzwungenes Pushen aktivieren, indem Sie Git Push erzwingen als Versionsverwaltung auswählen, insbesondere wenn Sie auf einen anderen Branch pushen.
- Zusammenführen (Merge)
Änderungen im Upstream-Repository werden in Weblate zusammengeführt. Bei dieser Einstellung wird, wenn möglich, Fast-Forward verwendet. Dies ist der sicherste Weg, kann aber eine Menge Merge Commits erzeugen.
- Zusammenführen (Merge) ohne Fast-Forward
Änderungen im Upstream-Repository werden in Weblate zusammengeführt, wobei jedes Mal ein Merge Commit durchgeführt wird (auch wenn ein Fast-Forward möglich wäre). Jede Weblate-Änderung wird als Merge Commit im Weblate-Repository angezeigt.
Der Standardwert kann durch DEFAULT_MERGE_STYLE geändert werden.
Commit-, Add-, Delete-, Merge-, Erweiterungs- und Merge-Request-Nachrichten¶
Nachricht, die beim Committen einer Übersetzung verwendet wird, siehe Auszeichnungsvorlage.
Die Standardwerte können durch das Setzen von DEFAULT_ADD_MESSAGE, DEFAULT_ADDON_MESSAGE, DEFAULT_COMMIT_MESSAGE, DEFAULT_DELETE_MESSAGE, DEFAULT_MERGE_MESSAGE und DEFAULT_PULL_MESSAGE geändert werden.
Bei Commit gleichzeitig Pushen¶
Ob committete Änderungen automatisch in das Upstream-Repository gepusht werden sollen. Wenn diese Option aktiviert ist, wird der Push ausgelöst, sobald Weblate Änderungen in das zugrunde liegende Repository committet (siehe Lazy Commits). Um das Pushen tatsächlich zu aktivieren, muss auch die Repository-Push-URL konfiguriert werden.
Alter der Änderungen, bis ein Commit erfolgt¶
Legt fest, wie alt (in Stunden) Änderungen sein müssen, bevor sie durch eine Hintergrundaufgabe oder den Verwaltungsbefehl commit_pending committet werden. Alle Änderungen in einer Komponente werden committet, sobald es mindestens eine Änderung gibt, die älter als dieser Zeitraum ist.
Der Standardwert kann durch COMMIT_PENDING_HOURS geändert werden.
Hinweis
Es gibt andere Situationen, in denen ausstehende Änderungen committet werden können, siehe Lazy Commits.
Sperre bei Fehler¶
Sperrt die Komponente (und verlinkte Komponenten, siehe Weblate-interne URLs) beim ersten fehlgeschlagenen Push oder Merge in das Upstream-Repository oder beim Pull daraus. Dies vermeidet das Entstehen weiterer Konflikte, die manuell gelöst werden müssten.
Die Komponente wird automatisch entsperrt, sobald keine Repository-Fehler mehr vorhanden sind.
Ausgangssprache¶
Sprache, die für die Ausgangszeichenketten verwendet wird. Ändern Sie dies, wenn Sie aus einer anderen Sprache als Englisch übersetzen.
Hinweis
Wenn Sie zweisprachige Dateien aus dem Englischen übersetzen, aber auch in der englischen Übersetzung Korrekturen vornehmen möchten, wählen Sie Englisch (Entwickler) als Ausgangssprache, um Konflikte zwischen dem Namen der Ausgangssprache und der vorhandenen Übersetzung zu vermeiden.
Für einsprachige Übersetzungen können Sie in diesem Fall die Zwischenübersetzung verwenden, siehe Zwischensprachedatei.
Sprachenfilter¶
Regulärer Ausdruck, der zum Filtern der Übersetzung beim Scannen nach Dateimaske verwendet wird. Er kann verwendet werden, um die Liste der von Weblate verwalteten Sprachen einzuschränken.
Bemerkung
Sie müssen die Sprachcodes so auflisten, wie sie im Dateinamen erscheinen.
Einige Beispiele für die Filterung:
Filterbeschreibung |
Regulärer Ausdruck |
|---|---|
Nur ausgewählte Sprachen |
|
Sprachen ausschließen |
|
Nur Zwei-Buchstaben-Codes |
|
Nicht-Sprachdateien ausschließen |
|
Alle Dateien einschließen (Standard) |
|
Varianten regulärer Ausdruck¶
Regulärer Ausdruck, um die Varianten einer Zeichenkette zu bestimmen, siehe Zeichenkette-Varianten.
Bemerkung
Die meisten Felder können von Projektverantwortlichen oder Administratoren in der Weblate-Bedienoberfläche bearbeitet werden.
Priorität¶
Komponenten mit höherer Priorität werden Übersetzern zuerst angeboten.
Geändert in Version 4.15: Dies wirkt sich nun auch auf die Reihenfolge der übereinstimmenden Glossarbegriffe aus.
Eingeschränkter Zugriff¶
Bemerkung
Diese Funktion ist auf Hosted Weblate nicht verfügbar.
Standardmäßig ist die Komponente für jeden sichtbar, der Zugriff auf das Projekt hat, auch wenn die Person keine Änderungen an der Komponente vornehmen kann. Dies erleichtert die Einhaltung der Übersetzungskonsistenz innerhalb des Projekts.
Die Zugriffseinschränkung auf Komponenten- oder Komponentenlistenebene übernimmt die Zugriffsberechtigung für eine Komponente, unabhängig von den Berechtigungen auf Projektebene. Sie müssen den Zugriff auf die Komponente explizit gewähren. Dies kann erfolgen, indem Sie den Zugriff auf eine neue Benutzergruppe gewähren und Benutzer in diese Gruppe aufnehmen, oder indem Sie die Standardgruppen Benutzerdefiniert oder Privat der Zugriffssteuerung verwenden.
Der Standardwert kann in DEFAULT_RESTRICTED_COMPONENT geändert werden.
Hinweis
Dies gilt auch für Projektadministratoren – bitte stellen Sie sicher, dass Sie den Zugriff auf die Komponente nicht verlieren, nachdem Sie den Status umgeschaltet haben.
Als Glossar verwenden¶
Added in version 4.5.
Ermöglicht die Verwendung dieser Komponente als Glossar. Sie können mit der Glossarfarbe konfigurieren, wie es aufgelistet werden soll.
Das Glossar ist in allen durch In Projekten teilen definierten Projekten zugänglich.
Es wird empfohlen, Zeichenketten verwalten für Glossare zu aktivieren, um das Hinzufügen neuer Wörter zu ermöglichen.
Siehe auch
Glossarfarbe¶
Anzeigefarbe für ein Glossar, die bei der Anzeige von Wortübereinstimmungen verwendet wird.
Kategorie¶
Kategorien sind dazu da, Komponenten innerhalb eines Projekts zu strukturieren. Sie können sie verschachteln, um eine komplexere Struktur zu erhalten.
Auszeichnungsvorlage¶
Weblate verwendet eine einfache Auszeichnungssprache an mehreren Stellen, an denen die Darstellung von Text erforderlich ist. Sie basiert auf The Django template language, kann also recht mächtig sein.
Derzeit wird es verwendet in:
Commit-Nachricht-Formatierung, siehe Komponentenkonfiguration
- Mehrere Erweiterungen
Die folgenden Variablen sind in den Komponentenvorlagen verfügbar:
{{ language_code }}Sprachcode
{{ language_name }}Sprachenname
{{ component_name }}Komponentenname
{{ component_slug }}Komponenten-Slug
{{ project_name }}Projektname
{{ project_slug }}Projekt-Slug
{{ url }}Übersetzungs-URL
{{ filename }}Übersetzungsdateiname
{{ stats }}Übersetzungsstatistiken, die weitere Attribute haben, Beispiele unten.
{{ stats.all }}Gesamtzahl der Zeichenketten
{{ stats.fuzzy }}Anzahl der zu überprüfenden Zeichenketten
{{ stats.fuzzy_percent }}Prozentsatz der zu überprüfenden Zeichenketten
{{ stats.translated }}Anzahl der übersetzten Zeichenketten
{{ stats.translated_percent }}Prozentsatz der übersetzten Zeichenketten
{{ stats.allchecks }}Anzahl der Zeichenketten mit fehlgeschlagenen Qualitätsprüfungen
{{ stats.allchecks_percent }}Prozentsatz der Zeichenketten mit fehlgeschlagenen Qualitätsprüfungen
{{ author }}Autor des aktuellen Commits, nur im Commit-Bereich verfügbar.
{{ addon_name }}Name der aktuell ausgeführten Erweiterung, nur in der Commit-Nachricht der Erweiterung verfügbar.
Die folgenden Variablen sind im Repository-Browser oder in den Editorvorlagen verfügbar:
{{branch}}Aktueller Branch
{{line}}Zeile in der Datei
{{filename}}Dateiname, man kann auch führende Teile mithilfe des Filters
parentdirentfernen, zum Beispiel{{filename|parentdir}}
Hinweis
An einigen Stellen können zusätzliche Variablen verfügbar sein, siehe Komponentenerkennung.
Es kann mit Filtern kombiniert werden:
{{ component|title }}
Es können Bedingungen verwendet werden:
{% if stats.translated_percent > 80 %}Well translated!{% endif %}
Für das Ersetzen von Zeichen ist ein zusätzliches Tag verfügbar:
{% replace component "-" " " %}
Es kann mit Filtern kombiniert werden:
{% replace component|capfirst "-" " " %}
Es gibt auch zusätzliche Filter, um mit Dateinamen zu arbeiten:
Directory of a file: {{ filename|dirname }}
File without extension: {{ filename|stripext }}
File in parent dir: {{ filename|parentdir }}
It can be used multiple times: {{ filename|parentdir|parentdir }}
… und andere Django-Vorlagenfunktionen.
Importierungsgeschwindigkeit¶
Das Abrufen des VCS-Repositorys und der Import der Übersetzungen in Weblate kann je nach Übersetzungsumfang ein langwieriger Prozess sein. Hier sind einige Tipps:
Optimieren der Konfiguration¶
Die Standardkonfiguration ist zum Testen und Debuggen von Weblate nützlich, während Sie für eine Produktionseinrichtung einige Anpassungen vornehmen sollten. Viele von ihnen haben einen großen Einfluss auf die Leistung. Bitte schauen Sie sich Produktionseinrichtung für weitere Details an, insbesondere:
Celery für die Ausführung von Hintergrundaufgaben konfigurieren (siehe Hintergrundaufgaben mit Celery)
Überprüfen der Ressourcenlimits¶
Wenn Sie umfangreiche Übersetzungen oder Repositorys importieren, kann es sein, dass Sie an die Grenzen Ihrer Serverressourcen stoßen.
Überprüfen Sie den freien Arbeitsspeicher. Wenn das Betriebssystem die Übersetzungsdateien zwischengespeichert hat, wird die Leistung erheblich besser sein.
Festplattenoperationen können zu Engpässen führen, wenn viele Zeichenketten zu verarbeiten sind – die Festplatte wird sowohl von Weblate als auch von der Datenbank belastet.
Zusätzliche CPU-Kerne können die Leistung von Hintergrundaufgaben verbessern (siehe Hintergrundaufgaben mit Celery).
Deaktivieren nicht benötigter Qualitätsprüfungen¶
Einige Qualitätsprüfungen können recht aufwendig sein, und wenn sie nicht benötigt werden, können Sie beim Import etwas Zeit sparen, wenn Sie sie weglassen. Siehe CHECK_LIST für Informationen zur Konfiguration.
Automatisches Erstellen von Komponenten¶
Falls Ihr Projekt Dutzende von Übersetzungsdateien hat (z. B. für verschiedene gettext-Domänen oder Teile von Android-Apps), möchten Sie diese vielleicht automatisch importieren. Dies kann entweder über die Befehlszeile mit import_project oder import_json erfolgen oder durch die Installation der Erweiterung Komponentenerkennung.
Um die Erweiterung zu verwenden, müssen Sie zunächst eine Komponente für eine Übersetzungsdatei erstellen (wählen Sie diejenige, bei der die Wahrscheinlichkeit am geringsten ist, dass sie in Zukunft umbenannt oder entfernt wird) und die Erweiterung auf dieser Komponente installieren.
Für die Verwaltungsbefehle müssen Sie ein Projekt erstellen, das alle Komponenten enthält, und dann import_project oder import_json ausführen.
Siehe auch