Ich würde gerne die Möglichkeit sehen, dynamische Bindungen im aot-Modus durchzuführen. Es gibt insbesondere zwei Anwendungsfälle, die begründen, warum dies in die Roadmap aufgenommen werden sollte.

Der erste ist der grundlegende Anwendungsfall, bei dem Sie keine separaten Anwendungen für jede Sprache wünschen. Dies erfordert eine Art Umleitungslogik außerhalb der App und erlaubt keine dynamische Änderung der Sprache ohne ein vollständiges Neuladen der Website.

Der zweite ist der Fall, in dem Sie die App mit Cordova in das Handy einbetten. Soweit ich weiß, haben Sie die Wahl, zu jiten, wodurch die Website verlangsamt wird, eine separate App für jede Sprache erstellt wird oder jede Sprache in die App aufgenommen wird (was sie natürlich aufbläht). Keines davon sind gute Optionen. Es scheint, dass Ionic i18n nicht verwendet, und ich frage mich, ob dies der Grund dafür ist.

@ jlutz777 das sind 2 gültige Anwendungsfälle, dieses Thema wurde in letzter Zeit intern diskutiert und ich habe mich auch dafür eingesetzt. Angesichts der Funktionsweise von i18n und AoT in Angular ist dies noch nicht ohne Weiteres möglich, aber dies könnte in Zukunft der Fall sein, sobald wir den neuen Kompilierungsprozess für AoT in v5 erhalten.
Ich werde es einmal in die Roadmap aufnehmen/wenn wir etwas Offizielles und Konkretes darüber haben.

Ich arbeite an der Electron + Angular 2-App und versuche jetzt, Unterstützung für die Lokalisierung für mehrere Sprachen hinzuzufügen, indem ich die i18n-Funktion mit Angular verwende. Tatsächlich ist das Extrahieren der Vorlagenzeichenfolge und das Konvertieren in verschiedene Sprachdateiformate klar dokumentiert, obwohl ich immer noch nicht viel darüber weiß und suche:

• Kann ich die Sprache dynamisch umschalten? oder muss ich die Anwendung für verschiedene Sprachen separat erstellen.
• Kann ich alle Strings an einer Stelle (in Form von Schlüssel/Wert-Paaren) verwalten/konsolidieren, damit ich mich ändern kann
  die Saite an einer Stelle an mehreren Stellen zu bewirken?
• Kann ich von einer anderen Stelle als der Vorlage auf die lokalisierte Datei zugreifen, um eine bestimmte Sprachzeichenfolge zu erhalten?
  bereitgestellter Schlüssel? (wie ich oben gefragt habe).

Die Punkte 2 und 3 werden mit dem Feature "Use translation strings outside of a template - #11405" gelöst.
Für Punkt 1 siehe die Antwort, die ich @jlutz777 oben gegeben habe. Im Moment müssen Sie die App noch in mehreren Sprachen erstellen oder JIT verwenden, das Übersetzungen beim Bootstrap dynamisch laden kann (es wechselt nicht zur Laufzeit, ist aber immer noch besser, als es x-mal bündeln zu müssen).

Die in einer Anwendung verwendete UI-Sprache sollte etwas sein, das nicht das Erstellen mehrerer Versionen derselben Anwendung erfordert. Dies sollte in keiner Weise ein "Compiler" -Problem sein. Wenn ja, dann ist der Compiler fehlerhaft. Das Problem sollte darin bestehen, das Anwendungsdesign so zu gestalten, dass der Text zur Laufzeit aus einer Datendatei geladen werden kann. das sollte mit einem Modul / einer Bibliothek geschehen, die wie jedes andere geladen und verwendet werden kann. machen Sie das überhaupt nicht zu einer Compiler-Funktion.

@figuerres es ist etwas, das in Zukunft geändert werden wird, noch keine Versprechungen, aber wir sind uns dieses Problems bewusst und prüfen mögliche Lösungen, die Verwendung einer externen Datei ist eine davon

Hallo @ocombe - Es sieht so aus, als würden wir wahrscheinlich i18n in Angular für unsere Anwendung verwenden. Gibt es Funktionen in der Dokumentation, von denen Sie glauben, dass sie in den kommenden Monaten veraltet sein könnten oder bahnbrechende Änderungen erfahren? Jede Info wäre sehr dankbar. Und nochmals vielen Dank für die DVD!

Hey @rjsteinert! Gut zu wissen!
Derzeit ist nur eine bahnbrechende Änderung geplant, nämlich die automatische Generierung von IDs. Die Methode ändert sich und die IDs stimmen nicht mehr überein, aber es wird ein CLI-Migrationstool geben, um Ihre Übersetzungsdateien zu aktualisieren (und einen Parameter, den Sie verwenden können, um nur zu migrieren, wenn Sie bereit sind).

Ich habe heute viel zu diesem Thema gegoogelt und frage mich, ob es eine "einfache" Lösung geben könnte, wie das Ersetzen von i18n-Tags durch einen Anruf bei einem Dienst anstelle der Übersetzung?

Aktuell:
<span i18n>Hello world</span> => gerendert zu <span>Hello world</span>

Meine Idee:
<span i18n>Hello world</span> => zu <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span> gerendert

Auf diese Weise könnte die eigentliche Übersetzung in AOT dynamisch erfolgen, da der Dienst aus einer API, Datei usw. gefüllt werden könnte, und selbst das Wechseln der Gebietsschemas wäre nicht viel mehr als i18nservice.setLocale('de-DE') beim Laden einer neuen Quelle.
Die Textextraktion mit dem xi18n-Tool würde weiterhin wie zuvor funktionieren und wir könnten die ohnehin generierten Nachrichten-IDs nutzen, um sie als Index für den Übersetzungsdienst zu verwenden.
Die aktuelle Implementierung würde auch weiterhin einwandfrei funktionieren, da ngc einfach nach einem "--use-i18nservice"-Flag suchen und ansonsten wie bisher kompilieren könnte.

Ein Problem, das ich derzeit identifizieren kann, ist die Injektion des i18nservice in jede einzelne Komponente, da er im Komponentenkontext existieren muss, um aufrufbar zu sein, aber das sollte auf die eine oder andere Weise lösbar sein.

Irgendwelche Gedanken dazu?

Es ist eines der Dinge, die wir in Betracht ziehen, ja, es gibt immer noch das Problem, wie Codeblöcke innerhalb dieser Übersetzungen behandelt werden, wenn der Compiler zur Laufzeit (AOT) nicht verfügbar ist. Das würde bedeuten, dass wir innerhalb von Übersetzungen keine eckigen Komponenten/Direktiven/Pipes verwenden können...

Ja, daran habe ich nicht gedacht.
Ich entwickle derzeit einen POC/Workaround, der alle Übersetzungen im Build-Schritt (Webpack) in das HTML einfügt und sie mit ng-switch in ng-Container verpackt.
Für i18n-Attribute verwendet es eine Direktive, die sie auf nativeElement setzt.
Die Übersetzungen selbst werden dann auch "gerendert", um all diese <x id=".. "/> Platzhalter zu ersetzen.

Es ist hässlich, aber funktioniert ... kann es kaum erwarten, dass ng es nativ unterstützt.
Werde den POC noch diese Woche veröffentlichen, vielleicht kann er für deine weitere Konzeption von Nutzen sein.

Ich habe mir eine "Lösung" ausgedacht, die meinen Bedürfnissen entspricht, bis es eine Implementierung gibt.
Der Preloader rendert jetzt HTML für alle Locales, bevor er an den Compiler übergeben wird, funktioniert bisher wie ein Zauber.

Repository: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng-i18n-aot-loader

möglicherweise könnte eine Komponente ein Attribut haben, das dem System / Compiler mitteilt, dass es einen Dienst benötigt.
Dieser Dienst nimmt dann eine ID und ein Gebietsschema und gibt den lokalisierten Text / das lokalisierte Markup zurück.
Der gesamte lokalisierte Text wird auf dem Server als Ressourcen gespeichert, aus denen der Dienst lesen kann.

wenn eine Komponente das Attribut no locale runtime nicht hat.
Wenn die Komponente es hat, ruft sie die lokalisierten Daten zur Laufzeit ab.
Der Compiler erstellt nur die Datendateien und verbindet den Dienst.

Dies scheint mir eine gute Möglichkeit zu sein, die häufigsten Anforderungen für die meisten Anwendungen zu erfüllen, ohne dass Websites mehrere Kopien derselben App erstellen und verwalten müssen.

Die Idee hatte ich auch.
Das Problem ist, dass Übersetzungen Bindungen enthalten können und somit das System für Code-Injektionen öffnen würden, wenn Übersetzungsdateien von externen Ressourcen geladen werden.
Außerdem wäre ein Compiler erforderlich, um diese Bindungen je nach Übersetzung dynamisch aufzulösen.

IMHO könnte eine gültige Lösung die Art und Weise sein, wie ich als POC (siehe Kommentar oben) implementiert habe, um Übersetzungen zur Kompilierungszeit zu inlinen, nur auf elegantere, integrierte Weise.
Beide oben genannten Probleme wären beseitigt, einziger Nachteil, den ich mir vorstellen kann, ist möglicherweise die Bundle-Größe, die auf "einfaches Bundle" + (übersetzte HTML-Größe * Locales) anwachsen würde.
Dies könnte verringert werden, indem nur ng-switch das i18n -getaggte HTML anstelle des gesamten Dokuments gesendet wird, aber es gibt immer noch ein Problem mit i18n-* -Tags.

Nun, hier ist das Ding; manchmal hat man grenzen....

Aus praktischer Sicht wäre es besser, das nicht zu haben, Sie können einen Textabschnitt haben, der in mehreren Sprachen angegeben werden kann. Das Ende der Geschichte.

Sie müssen einen datengebundenen Chunk haben? ok, aber das ist nicht im internationalisierten Text, es muss separat sein. Sie können weiterhin HTML und CSS verwenden, um das Ergebnis zu stylen und zu formatieren. Sie können sie jedoch nicht auf jede erdenkliche Weise einbetten oder kombinieren.
Beispielsweise kann ein div- oder ap-Tag eine Reihe von Spannen haben, eine Spanne ist der Text und eine andere Spanne ist ein gebundenes Datum. Die Textspanne ist an den i18n-Gebietsschemadienst gebunden. Das Datum ist an einen Datumsdienst gebunden, in dem sich die beiden Spannen befinden a Absatz-Tag, das sie formatiert.

Halten Sie es einfach, sorgen Sie dafür, dass es für 95 % aller Benutzer funktioniert, und finden Sie dann die Grenzfälle heraus.

Ich sehe das nicht als Grenzfall, es ist wie immer.
Angular ist ein Business-Framework, so dass viele, wenn nicht alle i18n-Benutzer Bindungen oder zumindest Pluralisierung und Auswahl innerhalb von Texten benötigen werden.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
Wie würden Sie das mit getrennten Zeichenfolgen lösen?
Einfache Antwort: Sie können nicht, da Sie die Regeln der Zielsprache nicht kennen, nicht jede Sprache folgt dem Format 'Begrüßung', 'Geschlecht', 'Name'.

Das Trennen dieser Stücke würde:

• Kontext abbrechen, würde der Übersetzer die Bedeutung des vollständigen Satzes nicht verstehen
• Das Zusammenführen der Chunks in der richtigen Reihenfolge per CSS ist nicht möglich, Sie müssten Regeln für jede einzelne Übersetzung festlegen, also muss entweder der CSS-Leute die Zielsprachen kennen oder der Übersetzungsmensch CSS ist akzeptabel.

Der Core i18n arbeitet erwartungsgemäß kantig und ist für Business-Apps nutzbar, das einzige, was anscheinend fehlt, ist die AOT-Kompatibilität, daher verstehe ich Ihren Standpunkt nicht, warum ein leistungsstarkes, funktionierendes System durch etwas ersetzt werden sollte, das nicht halb so fähig ist erfordert ein Vielfaches der Arbeit, um es zu erledigen.

Wir haben morgen ein Treffen, um eine Lösung für dieses Problem zu finden.

@ocombe freut mich, das zu hören, ich hoffe, dies führt zu einigen guten Dingen für eine zukünftige Version von Angular , hier bei der Arbeit lieben wir wirklich, wie das meiste davon für unsere Entwicklungsanforderungen funktioniert!

@ocombe , ist es möglich, die Sprache zu ändern, ohne das gesamte Dokument neu zu laden? Ich erkläre :
Ich bin auf der Seite mit dem Namen "about", aber wenn ich die Sprache ändere, werde ich auf die Haupteingangsseite meiner Anwendung umgeleitet.

Bei der Arbeit an meiner i18n-App bin ich auch auf den bekannten "Bug" gestoßen, dass externe Stylesheets von zB @angular/material (die sich in node_modules befinden) nicht aufgelöst werden konnten und somit das ng-xi18n -Tool versagte.
Ich habe einen „fehlende Dateien ignorieren“-HostContext für das Extraktionstool implementiert, ebenfalls als POC, aber als PR #17845 hinzugefügt, um ihn mit dem Hauptrepo zu verknüpfen.

@ocombe , da du in diesem Thema sehr aktiv zu sein scheinst, würde es dir etwas ausmachen, einen Blick auf die PR zu werfen und Feedback zu geben?

Danke, ich schaue mir das mal an.

Es hat einige Tage gedauert, bis nach einer Möglichkeit gesucht wurde, die Internalisierung für das gesamte Projekt einschließlich dynamischer Daten zu implementieren, aber nichts Konkretes gefunden. Können Sie mir bitte etwas anderes vorschlagen, das mir zumindest vorerst hilft. Danke.

Hallo @ocombe! Können wir den von @jlutz777 angesprochenen Punkt weiterverfolgen (über dynamische Bindungen, also nicht über eine App pro Sprache)?

Vielen Dank für Ihre Arbeit!

@vicb arbeitet gerade daran, es wird in 5.x sein (nicht 5.0, aber höchstwahrscheinlich 5.1)

@ocombe Soll die Checkliste aktualisiert werden? Ich kann sehen, dass einige von ihnen bereits in neueren Versionen zusammengeführt wurden. Und das wird Ihre harte Arbeit besser widerspiegeln. 😃

Ja, gute Idee, ich werde es aktualisieren
edit: aktualisiert

Runtime i18n (ein Paket für alle Gebietsschemas mit AOT) - [daran arbeiten]

Wo ist das zugehörige Thema / PR / Diskussion?

Es wäre cool, eine API zum Erweitern benannter Datumsformate (z. B. ultraLongDate ) zu haben, damit die native Datumspipe davon Kenntnis hat und eine benutzerdefinierte Datumspipe nicht benötigt wird.

Ich bin nur neugierig auf die Fortschritte bei "Runtime i18n (ein Paket für alle Gebietsschemas mit AOT)".

Mein Team hat mehrere große Apps mit über 60 Sprachen. Im Moment führen wir N Builds parallel aus, sodass N die Anzahl der Sprachen ist. Wie Sie sich vorstellen können, ist dies ressourcenintensiv, insbesondere wenn man bedenkt, dass die Apps ziemlich groß sind und viele Male am Tag in mehreren Umgebungen bereitgestellt werden.

Was ich erhoffe ist:

1. Einige grobe ETA zur Laufzeit i18n
2. Bestätigung, dass Runtime i18n einen einzigen Build für alle Sprachen durchführt
3. Ob jede produzierte Sprache faul ladbar ist oder in einem einzigen massiven Paket enthalten ist

@chcaru , während Sie darauf warten, dass ng eine "native" Lösung bereitstellt, schauen Sie sich https://github.com/actra-development-oss/ng-i18n-aot-loader/ an.
Es bietet genau das, wonach Sie fragen, einen AOT-Build mit mehreren Gebietsschemata.

@chcaru :
1/ grobe ETA ist Angular v6 (erste Beta sollte bis Ende Januar sein, glaube ich? nicht sicher), die gute Nachricht ist, dass Codeübersetzungen schnell nach Laufzeitübersetzungen folgen sollten, da fast die gesamte Arbeit erledigt sein wird
2/ ja
3/ Übersetzungen sollten vom Bundle getrennt werden, Sie können die benötigte Lazy Load vor dem Bootstrap laden oder einfach alles in einem bündeln. Wir möchten auch Lazy Loading-Übersetzungen für Module unterstützen, sind uns aber nicht sicher, wann dies der Fall sein wird verfügbar sein

@ocombe Bis zur Veröffentlichung von anglev6 ist ngx-translate die ernsthafteste Option, um Übersetzungen dynamisch zu laden und/oder eine mehrsprachige Anwendung mit einem einzigen Paket zu erstellen.

Haben Sie einige Tipps, um Leuten zu helfen, die mit ngx-translate beginnen, um einfach zu migrieren, wenn anglev6 nicht mehr verfügbar ist?
Irgendeine Brücke zwischen beiden Anwendungen?

Nicht wirklich, der Code ist ganz anders ... wir werden sehen, wann v6 mit diesen Funktionen herauskommt, wenn ich motiviert bin, an einem Migrationstool zu arbeiten

Hallo, danke für die Transparenz der kommenden Features.

Es wäre sehr hilfreich, Antworten auf folgende Fragen zu wissen:

1. Irgendeine Idee, wie unterschiedlich der neue i18n-Workflow von dem aktuellen sein wird, der in https://angular.io/guide/i18n beschrieben wird?

2. Wird das Attribut i18n und i18n-*, z. B. i18n-title, mit optionaler benutzerdefinierter ID weiterhin in Vorlagen verfügbar sein?

3. Funktionieren die folgenden Befehle noch?

ng serve --aot --locale fr

ng xi18n  --i18nFormat=xlf
ng xi18n  --i18nFormat=xlf2
ng xi18n  --i18nFormat=xmb

1. Wie werden die trans-Einheiten von messages.xlf, die aus Vorlagen extrahiert werden, mit denen zusammengeführt, die im Code verwendet werden?

1. Wir werden das Update-Erlebnis so reibungslos wie möglich gestalten, höchstwahrscheinlich wird das, was vorher funktioniert hat, auch danach noch mindestens bis v7 funktionieren.
2. Die i18n-Attribute bleiben gleich
3. Die Extraktion sollte auch die gleiche sein
4. das ist wahrscheinlich der einzige Teil, der sich ändern wird, ich bin mir noch nicht sicher, wie, also ziehe ich es vor, Ihnen nichts zu sagen, was sich ändern könnte, aber die Nachrichten werden zur Laufzeit zusammengeführt, wenn die Ansichten erstellt werden (also zwischen Bootstrap und der Ansicht, die auf erscheint der Bildschirm)

Nach dem Kommentar von @Toub wären wir für diese Übergangszeit an Rückmeldungen für den folgenden Ansatz (Mischen von i18n-Attribut und ngx-translate) interessiert, den wir implementieren möchten. Unser Ziel ist es, die Aktualisierungen im Code zu minimieren, wenn die neue i18n-Unterstützung bereit ist.

(Beachten Sie, dass wir dynamische Gebietsschemas wollen, dh nicht eine generierte App pro Gebietsschema)

• Wir werden das Attribut i18n verwenden, damit wir das Winkelextraktionswerkzeug nutzen können.
• Basierend auf dem extrahierten Tool können wir xliff-Dateien (oder mit anderen Formaten) in Inhalte mit Formaten konvertieren, die von ngx-translate (json oder po) verwendet werden können.
• Wir werden das Attribut translate auf Elemente anwenden, die das Attribut i18n verwenden, um Übersetzungen anzuwenden (zuvor extrahiert).

Hier ist ein Beispiel:

<!-- Without parameters -->
<div i18n="hello-id" translate>HELLO</div>

<!-- With parameters -->
<div i18n="hello-id" translate [translateParams]="{value: 'world'}">HELLO</div>

Vielen Dank für Ihre Rückmeldungen!

Könnten Sie dafür ein Problem auf ngx-translate eröffnen? Ich denke, das Beste wäre wahrscheinlich, die Bibliothek zu aktualisieren, um "i18n" -Attribute als Alternative zu "übersetzen" zu unterstützen.

@ocombe danke für den Vorschlag! Ich habe gerade ein Problem dafür auf ngx-translate hinzugefügt ...

@ocombe das Problem, das ich sehen kann, ist, dass i18n / i18n-* Attribute zur Laufzeit entfernt werden (https://github.com/angular/angular/issues/11042). Gibt es eine Möglichkeit, sie zu behalten?

Ich habe es überprüft und wenn ich mich nicht irre, werden sie nur entfernt, wenn Sie Angular i18n verwenden (was bedeutet, dass Sie Übersetzungen laden, wenn Sie die Kompilierung durchführen).

@ocombe Ich verstehe, aber ich lade die Übersetzungen nicht, da ich Angular CLI verwende und die Anwendung mit ng serve gestartet habe ...

@ocombe , unser Unternehmen wird sich bald bemühen, i18n mit der derzeit vorgeschriebenen Strategie mehrerer Apps pro Gebietsschema zu unterstützen. Wir planen auch, das Gebietsschema in die URL aufzunehmen und die Basis-href in der App festzulegen. Welche Änderungen müssten wir an unserer URL-Gebietsschema-Strategie vornehmen, sobald das Laufzeit-i18n-Feature abgeschlossen ist? Gibt es einen besseren Weg, um eine große Umgestaltung zu vermeiden, sobald die Laufzeit i18n veröffentlicht ist? Danke für deine Arbeit an all dem.

⬆️ sollte sagen "wird bald beginnen"

Eine App/ein Gebietsschema sollte immer noch so funktionieren, wie es jetzt ist (abzüglich der kleinen Änderung, um die Gebietsschemadatei beim Bootstrap zu laden, wenn Sie das CLI nicht verwenden)

Könnte mir bitte jemand sagen, in welcher Datei i18n -Attribute während des Bundles aus der Vorlage entfernt werden?

cc @ocombe

Es wurde in 4.2.6 geändert (PR https://github.com/angular/angular/issues/17999)

Hallo! Ich verfolge diesen Thread schon länger. Ich habe gesehen, dass die erste Beta für v6 draußen ist. Ich habe das Änderungsprotokoll gelesen, aber nichts im Zusammenhang mit diesem seit langem bestehenden Problem gesehen. Irgendwelche Neuigkeiten an dieser Front? Oder gibt es zumindest eine Garantie dafür, dass die Schnittstelle Ihrer Polyfill ähnlich ist?

Danke für deine Arbeit!

Es wird in einer der letzten Betas sein, oder vielleicht RC (ich weiß, ich weiß ...).
Die Schnittstelle wird ab der Schließung goog.getMsg ähnlich sein, da Google diese intern für Codeübersetzungen verwendet: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
Aber wir verwenden möglicherweise einen Wrapper, also ändert er vielleicht die Schnittstelle für Angular, noch nicht sicher.
In meinem Polyfill verwende ich eine ähnliche Schnittstelle, aber mit der Möglichkeit, bei Bedarf ID, Beschreibung und Bedeutung zu definieren, und ich glaube, dass wir das auf die eine oder andere Weise brauchen werden (entweder über Parameter oder über einen Decorator).

Danke für all deine harte Arbeit! Wir bereiten uns auf eine grundlegende Neufassung unserer gesamten 1.x-App ab April vor. Gibt es etwas, was wir tun können/sollten, um uns auf diese Veränderungen vorzubereiten? Im Moment planen wir die Verwendung von 6.x. Danke noch einmal!

@ocombe Nur neugierig, wann "Führende und nachgestellte Leerzeichen ignorieren" landen wird?

Ich muss die Roadmap aktualisieren, aber sie ist im Moment etwas verwirrt (selbst für mich). Insbesondere dieses Feature hat eindeutig keine Priorität, erwarten Sie nicht, dass wir in absehbarer Zeit daran arbeiten

@ocombe Ja, das wäre großartig. Auch wir interessieren uns sehr für die Laufzeit i18n, da sie für uns der einzige Sperrpunkt ist. Können Sie vielleicht eine Schätzung über die Fertigstellung in % abgeben?

Vielen Dank für Ihre Mühe!

@ocombe

Insbesondere dieses Feature hat eindeutig keine Priorität, erwarten Sie nicht, dass wir in absehbarer Zeit daran arbeiten

Könnten Sie erklären, von welcher Funktion Sie hier sprechen? Ich möchte keine Vermutungen anstellen.

@ofuangka Die Funktion "Führende und nachgestellte Leerzeichen ignorieren" hat keine Priorität.
@Karamuto im Moment schwer zu erraten, wir arbeiten gerade daran

@ocombe
Könnten Sie bitte Ihren Meilenstein zu Runtime i18n (ein Paket für alle Gebietsschemas mit AOT) teilen?

Jetzt entscheiden wir uns für die Verwendung von xi18n-Tools oder die Verwendung von Bibliotheken von Drittanbietern für ein riesiges mehrsprachiges Projekt.
Wir hoffen, kanonische Werkzeuge verwenden zu können, sind uns aber bewusst, dass sie zu roh sind.

Außerdem würden wir gerne xlf-Dateien aufteilen können (eine Datei pro Modul), ist das möglich?

nach oben nach oben
Wird die Laufzeit i18n in Angular 6 veröffentlicht?

danke und frohes codieren!

Ich verliere hier die Hoffnung, dass dies rechtzeitig fertig wird, da nicht mehr viel Zeit bleibt und es bisher keine Releases bezüglich dieses Features gab.

Die Veröffentlichung der Version 7 würde für uns ziemlich spät kommen.

@Karamuto #22654
Ich denke, es wird in Version 6 veröffentlicht, aber sie müssen Ivy zuerst fertigstellen.

Wir sollten diese Woche ein Hallo Welt haben, aber mit minimalen Funktionen (z. B. keine Unterstützung für die Intensivstation).
Aber da es mit Ivy veröffentlicht wurde, das sich hinter einer Flagge befindet, werden wir weiter daran arbeiten und es veröffentlichen, sobald wir ein neues Feature fertiggestellt haben, es besteht keine Notwendigkeit, auf v7 zu warten

@ocombe
Das klingt gut! Es muss nicht von Anfang an komplett mit ICU sein. Wenn es in den letzten Releases von v6 vorankommt, ist das für uns völlig in Ordnung.

Danke für die tolle Arbeit wieder!

@Karamuto siehe #22654 für einen kleinen Vorgeschmack!

Dumme Frage: Gibt es eine Möglichkeit, eine i18n-Direktive für stringbasierte Eingaben für benutzerdefinierte Komponenten zu haben. Ein Beispiel beim Weiterleiten von aria-labels:

Ich verpacke eine benutzerdefinierte Schaltfläche, die coole Dinge tut:

Die Vorlage der benutzerdefinierten Schaltfläche macht einfach Folgendes:

Gibt es dafür schon eine Möglichkeit?

@kekraft Ich denke, mit statischen Eingaben können Sie die i18n-Attributsyntax verwenden:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

In der Komponente:

<button [attr.aria-label]="ariaLabel">Some button</button>

@ocombe brauchen Sie Mitwirkende, um die Laufzeit-i18n- Arbeit zu erledigen?

Ja ! v6 veröffentlicht ~~~
gibt es hier ein Update?

das Beispiel i18n Winkel 6 ist hier
https://github.com/angular/angular/pull/23660

@sandangel meinst du einfach "alles" oder "alles was geprüft wird", aus den Plänen am Anfang dieses Threads?
Ich habe mich sehr auf eine einzige Bewerbung gefreut, ich denke, das ist eines der wichtigsten Dinge. Ging zu #23660, das Sie verlinkt haben, und erreichte dann https://pr23660-e12f469.ngbuilds.io/guide/i18n
Aber da heißt es noch:

Wenn Sie mit dem AOT-Compiler internationalisieren, müssen Sie für jede Sprache ein separates Anwendungspaket vorab erstellen und das entsprechende Paket basierend auf serverseitiger Spracherkennung oder URL-Parametern bereitstellen.

Ist es möglich, eine einzige Anwendung für mehrere Sprachen zu haben oder noch nicht?

@MrCroft sieht so aus, als ob die Laufzeit i18n noch in Arbeit ist. Ich habe es wie Sie gelesen, einige weitere Optionen, aber nicht ein Bündel für alle Lokalisierungen :(

Wir haben ein funktionierendes Hello World, aber es ist nur für den neuen Renderer (ivy) und da ivy nicht bereit für die Hauptsendezeit ist, müssen Sie leider darauf warten :(

@ocombe Also , wenn wir Ivy nicht in Produktion haben (wahrscheinlich um v7 herum), werden wir keine Laufzeitübersetzungen haben. ist das richtig?

@ocombe sind die Hello World- und Ivy-Sachen öffentlich verfügbar? Es wäre cool zu versuchen, diese neue i18next-Implementierung zu verstehen😃

@fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

@fetis ja :(
@feloy ja, die einfache Hallo Welt ist hier: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n aber sehr minimal
Sie finden die Tests hier: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
und etwas Refactoring + Extraktion hier: https://github.com/angular/angular/pull/22931

@ocombe Wir versuchen, i18n in unserer Anwendung zu implementieren, aber wo immer ich darüber lese, sehe ich, dass wir eine messages.xlf-Datei pro Sprache benötigen. Würde das nicht zu einem Aufwand werden, wenn man komplexe Anwendungen mit verschiedenen kundenorientierten Bildschirmen usw. in Betracht zieht. Ich möchte sehen, ob wir die Nachrichtendatei nach Komponente oder Modul aufschlüsseln können? Wird das schon unterstützt?

@stickler-v Diese Datei transportiert nur Ihre Zeichenfolgen zu Ihrer Übersetzungssoftware. erwägen Sie nicht, es manuell zu übersetzen.

Ich verstehe, wo haben wir eigentlich Text in verschiedenen Sprachen? Wir müssen diesen Text manuell verwalten, im Gegensatz zu Übersetzern.

Entschuldigung, aber ich bin etwas verloren. Basierend auf der Originaldokumentation hier https://angular.io/guide/i18n. src/app/app.component.html enthält nur englischen Text. messages.fr.xlf ist die Datei, die französischen Text enthält, aber automatisch generiert wird und nicht ratsam ist, sie zu berühren.

Wenn ich app.component.html mit französischem Text anstelle von englischem Text gerendert haben möchte, wo würde ich französische Nachrichten "Bonjour" usw. angeben?

@stickler-v es ist wirklich offtopic, bitte erstelle eine Frage zu StackOverflow. Dort antworte ich gerne.

Können Sie das hier bitte nicht diskutieren, das ist hier nicht das Thema, danke
Was Ihre Frage @stickler-v betrifft, eine Datei pro Modul / Komponente ist derzeit nicht möglich, dies könnte in Zukunft der Fall sein, steht jedoch nicht auf der Liste der Dinge, an denen wir gerade arbeiten

Gibt es Pläne, Routenübersetzungen zu unterstützen?

Entschuldigung, wenn dies bereits beantwortet wurde, aber sind mit dieser Version Übersetzungen in JS möglich oder handelt es sich immer noch nur um Vorlagen?

@santhony7 Es ist immer noch nicht möglich, da Ivy noch nicht bereit ist.

Eine Frage, die ich hier zur Absicht/Funktionalität von Runtime i18n habe, ist, ob das bedeutet, dass wir im Wesentlichen in der Lage sein werden, die Sprache zur Laufzeit auszuwählen und sie zu "umdrehen", ohne die App neu zu laden, wie es die Funktionalität im alten ng-translate war für AngularJS und in ngx-translate ? Oder bedeutet das etwas ganz anderes?

Nein, Sie müssen die App neu laden, um die Sprache zu ändern.

Mit dem aktuellen i18n ersetzen wir beim Erstellen und Bereitstellen Ihrer Übersetzungen die Zeichenfolgen im Bundle-Code, was bedeutet, dass das Bundle lokalisiert wird.
Runtime i18n bedeutet, dass die Übersetzungsdateien beim Start der App geladen werden und nicht wie jetzt zur Build-Zeit.
Aus diesem Grund können Sie die Übersetzungsdateien vor dem Start der App träge laden, was bedeutet, dass das Bundle von der Sprache getrennt ist und Sie nur ein Bundle für Ihre App erhalten.
Sie können sich auch dafür entscheiden, ein Paket pro Sprache zu haben und die Sprachdatei mit Ihrer App zu bündeln (wie wir es gerade tun), Sie vermeiden die Verzögerung, die erforderlich ist, um die Übersetzungsdatei träge zu laden.
In einem Fall machen Sie eine zusätzliche HTTP-Anfrage und im anderen Fall nicht, aber ich glaube nicht, dass der Unterschied groß genug sein wird, um ein Bündel pro Sprache zu rechtfertigen.

Vorteile der Laufzeit i18n:

• Erkennen Sie die Clientseite der Sprache und laden Sie die gewünschte Übersetzungsdatei träge
• Da der Code sprachunabhängig ist, erhalten Sie ein Paket für alle Sprachen
• Bibliotheken können auch "i18n"-kompatibel sein
• Da wir die Übersetzungen zur Laufzeit laden, haben wir alles, was wir brauchen, um einen Dienst bereitzustellen, der auch Übersetzungen in Ihrem Code durchführen kann (nicht nur die Vorlagen).
• wir könnten die Übersetzungen pro Modul aufteilen (vorerst wahrscheinlich nicht verfügbar)

Nachteile:

• Das Übersetzen zur Laufzeit verursacht geringe Kosten, wenn die Übersetzungen extrahiert und in HTML-Knoten umgewandelt werden, aber hoffentlich sollten Sie das nicht bemerken, da Ivy viel schneller sein wird als der aktuelle Renderer
• Der App-Bootstrap verzögert sich um die Zeit, die zum faulen Laden der Übersetzungen benötigt wird, oder Ihr Paket ist etwas größer (wenn Sie die Übersetzungen bündeln).
• Wir müssen die Serialisierer zu Ihrem App-Bundle hinzufügen, um die Übersetzungen lesen zu können, und das ist eine Menge Code (wir könnten die Übersetzungen wahrscheinlich in eine Art JSON "vorkompilieren", um dies zu vermeiden, wir haben uns noch nicht entschieden )

Theoretisch könnten Sie die Sprache ändern, ohne die gesamte App neu zu laden, aber Sie müssen die vorhandenen Komponenten neu erstellen, da die Vorlagen generiert werden, wenn die Komponente erstellt wird, oder Sie könnten den Dienst in Ihre Vorlage binden (anstatt i18n -Attribute) und es würde aktualisiert, wenn Sie die Sprache ändern. Es wäre möglich, eine Bibliothek zu schreiben, die wie ngx-translate funktioniert, aber intern Angular i18n verwendet und es Ihnen ermöglicht, die Sprache zur Laufzeit zu ändern. Es würde mehr Speicher verbrauchen, um die Vorlagen mit der Sprache synchron zu halten, wie es bei ngx-translate der Fall ist. Ich werde wahrscheinlich eine Bibliothek wie diese schreiben.

auch für die leute zu bedenken ist, dass einige änderungen von einer sprache zur anderen klein sein können, andere können groß sein, sagen sie, dass der wechsel von englisch zu spanisch "klein" sein könnte, aber von englisch zu sagen chinesisch oder arabisch wird groß sein.
Um klarzustellen, dass es bei einigen Sprachen nicht nur um den Text geht, müssen Sie möglicherweise auch ein anderes Layout entwerfen, um diese Sprache und ihre Regeln für die Ausrichtung von links nach rechts oder von rechts nach links und andere Details zu berücksichtigen.

Für die meisten Anwendungen in der realen Welt würde ich also erwarten, dass die App beim Laden der App einen Spracherkennungsschritt hat, der zum Laden der richtigen Ressourcen und einiger Layouts führt.

@ocombe Vielen Dank für die Klarstellung! Ich habe das aktuelle Angular i18n in unserer Anwendung implementiert und bin aufgrund von Änderungen/unbekannten Anforderungen auf einen Haken gestoßen. Ich verwende auch die https://github.com/ngx-translate/i18n-polyfill-Bibliothek in Verbindung, um die aktuelle Lücke zu schließen.

Während die mehreren Bündel ein leichtes Ärgernis sind, können Sie sie derzeit leicht genug umgehen. Der Haken ist insbesondere das Potenzial, eine Komponente (und alle untergeordneten Komponenten davon) in einer anderen Sprache als der aktuell verwendeten Sprache anzuzeigen.

Ehrlich gesagt bin ich mir noch nicht sicher, ob ngx-translate mir dabei helfen kann, aber ich wollte Sie über die bevorstehenden Änderungen informieren, nur um sicherzustellen, dass ich so viele Informationen wie möglich habe, bevor ich irgendwelche Pivots mache.

Wir haben nicht vor, Apps zu unterstützen, die gleichzeitig in mehrere Sprachen übersetzt werden, es könnte in Zukunft möglich sein, wenn wir Übersetzungen / Module laden können, aber das wäre ein Nebeneffekt der Architektur, nicht etwas, das wir speziell tun versucht zu erreichen.

Gibt es eine ETA für Ivy + Runtime i18n?
Ich verstehe vollkommen, wenn dies nicht der Fall ist, aber ich muss wissen, ob ich (angesichts des Zeitrahmens meines aktuellen Projekts) darauf warten kann oder eine der aktuellen Lösungen verwenden und die Migration zur Laufzeit i18n für eine zukünftige Version verschieben muss .

Ich werde nicht versuchen, einen genauen Zeitrahmen anzugeben, jedes Mal, wenn ich es versucht habe, war es falsch :D
Es wird jetzt nicht vor v7 sein (wird vorher als Beta verfügbar sein)

Kein Problem, wir alle wissen, dass Schätzungen immer falsch sind. :D
Glauben Sie, dass es einfacher sein wird, vom aktuellen i18n (+ i18n-polyfill) auf Runtime 18n oder von ngx-translate zu migrieren?

wahrscheinlich vom aktuellen i18n, aber ich werde eine Version von ngx-translate schreiben, die die Interna von Angular i18n verwendet, wenn es möglich ist (noch nicht sicher)

Hallo, ich habe versucht, diesen Thread zu durchqueren, um den aktuellen Stand zu verstehen. Ist der ngx-Übersetzungscode derzeit die praktikabelste „Umgehungslösung“ für eine einzelne App mit dynamischer Lokalisierung?

Hallo, ist es möglich, die Lokalisierung zur Laufzeit mit ngx-translate/i18n-polyfill zu ändern?

@suchg Nicht zur Laufzeit. Sie können zur Laufzeit Übersetzungen vornehmen, aber Sie können das verwendete Gebietsschema nicht ändern.

@mjschranz danke für die schnelle Antwort
Sogar die Laufzeitübersetzungen sind vorerst in Ordnung. können Sie ein Beispiel dafür teilen.
Ich habe das unter https://github.com/ngx-translate/i18n-polyfill freigegebene Beispiel ausprobiert und die Sprache des Chrome-Browsers geändert, aber kein Glück.
Gibt es eine bestimmte Methode für die Übersetzung?

Bitte führen Sie die Diskussion hier über Angular fort, nicht über externe Bibliotheken. Wenn Sie dabei Hilfe benötigen, posten Sie die Nachrichten in ihren Github-Repositories

Hey, gibt es noch andere Tracking-Probleme oder Design-Dokumente darüber, wie die Funktion in Zukunft aussehen wird? Vielleicht können wir bei der Implementierung helfen oder uns vorbereiten, um sicherzustellen, dass der Übergang in v7 so reibungslos wie möglich verläuft.

Hallo, ich verwende derzeit Angular 5 und wir müssen unserem Projekt mehrere Sprachen hinzufügen.
Ich habe eine Lösung hinzugefügt, die jetzt für mich funktioniert, was fast elegant ist. https://github.com/angular/angular/issues/24549.

Idealerweise möchte ich die Sprachdateien basierend auf einem Länder-Sniffer-Dienst (basierend auf einer Hostnamen-Kartensuche) faul laden.
Wenn das in Angular 6 möglich wäre, wäre das großartig.

@mattiLeBlanc Wie lösen Sie dynamische Nachrichten auf, zum Beispiel Nachrichten von Komponenten oder Diensten?

@zverbeta Bitte entschuldigen Sie, dass ich Angular Core oder den Kontext für diese Diskussion nicht vollständig verstehe. Ich kann es für den Anfang nur aus meinem Kontext angehen.

Um Ihre Frage zu beantworten, würde ich annehmen, dass wir nur daran interessiert sind, die Übersetzungsdateien (xlf) auf eine nette Art und Weise zu laden, basierend auf einem Gebietsschema, das aus der URL oder einem Sprachabfrageparameter abgeleitet werden kann. (Ich verwende derzeit eine URL-Zuordnung, um zu entscheiden, was das Gebietsschema ist).

Eine Nachricht von einer Komponente oder einem Dienst wird nicht so getaggt, wie wir das Markup mit i18n taggen. Ich habe einige Erfahrung mit i18n für Wordpress und PHP. Dort verwenden wir den __( 'text' to translate, 'text domain' ) -Ansatz, um die korrekte Übersetzung zu erhalten. Dieses __() könnte auch vom CLI-Befehl gescannt werden, der die Nachrichtendatei erstellt.

Ist dies eines der Probleme, auf die Sie sich beziehen?

Eine Sache ist mir zum Beispiel bei diesem Markup-Block aufgefallen (weil ich faul war und nicht jedem Unterelement i18n hinzufügen wollte):

<div class="eligibility-banner" i18n="@@eligbilityBanner" fxLayout="column" fxLayout.gt-xs="row" fxLayoutAlign.gt-xs="center center" fxLayoutAlign="center start">
        <div class="requirement-text" fxFlex="20">To be eligible, you:</div>

        <div fxLayout="column" fxFlex="80" fxLayout.gt-xs="row" fxLayoutAlign="center start">
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">own an Australian business (with a valid ABN/ACN)</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are over 18 years old</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are an Australian Citizen or Permanent Resident</div>
          </div>
        </div>
      </div>

das heißt, kopiert den gesamten div-Block in meine message.xlf.
Das ist eine Menge Markup-Verschmutzung. (Natürlich könnte ich i18n für jedes Tag verwenden, das Text enthält.)

Für dieses Beispiel würde die Verwendung des Befehls _e() ziemlich gut funktionieren, denke ich. Sie würden Ihren Text mit dem echo-Befehl umbrechen und all dieser umbrochene Text wird gesammelt. Sie könnten all diese Markup-Kopie in der XML loswerden.
Wenn Sie dieser Zeichenfolge etwas Dynamisches hinzufügen müssen, können Sie es mit Platzhaltern in der Zeichenfolge leiten (wie Sie es mit sprintf tun würden. So etwas wie

<p>{{ __( 'I would like a nice %s, please', fruit ) }}</p> 

wobei fruit eine Variable mit einem Wert von __( 'apple') oder __( 'pear) ist.
Die 3 Textteile würden im XML landen und können separat übersetzt werden.

Würde das was nützen? Es ist ziemlich ähnlich mit dem Hinzufügen des i18n-Attributs, wie ich nach dem erneuten Lesen merke :)

Betrachten wir abschließend einige der Formate. XLIFF 2 sieht ziemlich gut aus, etwas sauberer als 1.2. Das XMB sieht verwirrend aus, eine schreckliche Dokumentation, die aussieht, als wäre sie 1995 gestaltet worden.
Ich habe bei der Verwendung von XLIFF 2 festgestellt, dass der TARGET-Text nicht wie in Version 1.2 gerendert wurde.

Habt ihr euch .pot- und .mo-Dateien angesehen? Ziemlich einfaches Format und wird auch von Übersetzungen mit dem POEdit-Tool verwendet.

Ich muss meine Anwendung mithilfe der Umschalttaste in Englisch und Spanisch konvertieren. Habe alle Änderungen vorgenommen, Arbeitsdatei separat. Ich habe zwei Builds unter .dist/en und dist/es erstellt. Kann mir jemand sagen, was ich für die Bereitstellung tun muss und wie ich zwischen beiden Builds wechseln kann?

Was ich tun muss, wenn ich auf die Umschaltfläche klicke

@shobhit12345 Bitte posten Sie Ihre Hilfeanfrage auf https://stackoverflow.com

@zverbeta die Lösung, die ich unter #24549 gepostet habe, funktioniert nicht, wenn ich mit --prod baue. Irgendwie offensichtlich, da ich require verwende, was wahrscheinlich nicht verfügbar ist?
Ohne das Flag --prod funktioniert die Lösung, weil sie Webpack-bezogenen Code enthält?

@mattiLeBlanc Ich habe diese Bibliothek https://github.com/ngx-translate/i18n-polyfill gefunden und sie löst mein Problem mit dynamischem Text

Hallo, wie können wir dynamische Werte (Interpolation) mit i 18 n übersetzen.

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

Hey! Gibt es einen Ort, an dem wir die bearbeiteten Aufgaben verfolgen und/oder helfen können? (diejenigen, die daran arbeiten )

Irgendwelche Updates zu einem Zeitrahmen für die Veröffentlichung einer Beta-Version von Runtime i18n?

@marcelnem Ich kann den Kommentar nicht finden, aber iirc ocombe hat erwähnt, dass die Laufzeit i18n für Ivy zusammengeführt wird, sodass Sie sie wahrscheinlich auf der v7-Beta mit dem Ivy-Flag testen können

Der Runtime-Teil ist fertig, aber nicht der Compiler-Teil, was bedeutet, dass Sie ihn noch nicht mit Ivy testen können

Hallo, ich arbeite mit Angular 6 i18n. Ich arbeite mit mehreren Sprachen, was bedeutet, dass ich dem Kochbuch gefolgt bin:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

Meine aktuelle Implementierung verwendet AOT, also habe ich eine messages.xlf-Datei und eine messages.pt.xlf generiert. Alles funktioniert gut, wenn ich laufe

ng serve --configuration=pt

Ich bekomme Texte wie erwartet übersetzt. Aber ich habe das Gefühl, dass etwas mit der Art und Weise, wie es funktioniert, nicht stimmt. Wahrscheinlich fehlt mir etwas. Soweit ich verstanden habe, muss ich jedes Mal, wenn ich eine neue zu übersetzende Zeichenfolge hinzufüge und sie mit dem Attribut i18n markiere, die Datei messages.xlf mit "ng xi18n" neu generieren und dann die Datei messages.pt.xlf manuell aktualisieren. Die xlf-Datei enthält auch die Zeilennummer, in der sich die Quelle befindet. Wenn ich also die Zeile ändere, muss ich auch die Datei neu generieren und meine pt-Datei manuell aktualisieren.

<context context-type="linenumber">16</context>

Das sieht nicht schlau aus, es wird mir eine Menge zusätzlicher Arbeit geben, um es am Laufen zu halten. Verstehst du meine Sorge? Übersehe ich etwas?
Ich weiß, dass Angular 7 i18n ein großes Update mit Ivy haben wird, soll ich darauf warten?

Mit freundlichen Grüßen,
Fabio

ps Ich hoffe wirklich, dass dies nicht vom Thema abweicht, aber wenn Sie das Gefühl haben, geben Sie mir bitte zumindest eine Richtung. Wo soll ich das zum Beispiel fragen? Oder ob es einen Link gibt, der meine Zweifel beantworten könnte.

@fabiopcarvalho Eine Sache, die mir klar geworden ist, ist, dass es ratsam ist, benutzerdefinierte IDs für jede einzelne Übersetzung zu verwenden, um Änderungen im HTML-Layout leichter verfolgen zu können.

Aber ja, Sie müssen die Übersetzungsdatei routinemäßig aktualisieren.

@fabiopcarvalho Ich benutze xliffmerge , um mir beim Zusammenführen der Übersetzungen zu helfen

Perfekt, ich habe dieses Tool verwendet und es hat großartig funktioniert. Ich verwende auch die IDs und
sie helfen.
Danke für die Antwort !!

Am Donnerstag, den 30. August 2018, schrieb Pedro Romero [email protected] :

@fabiopcarvalho https://github.com/fabiopcarvalho Ich verwende xliffmerge
https://github.com/martinroob/ngx-i18nsupport , um mir bei der Zusammenführung zu helfen
der Übersetzungen

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TungRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

Das Zulassen von ICU-Nachrichten in Attributen ist für die Barrierefreiheit von entscheidender Bedeutung, da das Attribut aria-label häufig für die Barrierefreiheit verwendet wird. Gibt es ein Problem für die Nachverfolgung?

Ich glaube nicht, dass es dafür ein Problem gibt, könnten Sie eines eröffnen? Ich arbeite gerade an ICU-Ausdrücken für Ivy, also habe ich ein TODO hinzugefügt, aber eine Funktionsanfrage wäre besser

@ocombe , https://github.com/angular/angular/issues/21615

Perfekt danke (die Github-Suche ist wirklich schlecht!)!

Werden wir mit der neuen Version von i18n in der Lage sein, die Übersetzungsdateien von einer externen Quelle zum Beispiel über HTTP zu laden?

@ocombe wie Sie sagten, arbeiten Sie an Runtime i18n (ein Paket für alle Gebietsschemas mit AOT). Es ist über ein Jahr her, auf das wir warten. Wann können wir erwarten, dass diese Funktion in der Veröffentlichung von Angle 7 erscheint?

@Sef1995 ist eines der Dinge, die wir ermöglichen möchten
@AhmadShahid , es wird Ivy benötigt, das unabhängig von v7 veröffentlicht wird, und Ivy wird nicht für die Veröffentlichung von v7 bereit sein. Einige Teile von Ivy befinden sich bereits in v6 hinter einem Flag, aber es ist nicht vollständig und Sie sollten es nicht in einer realen Anwendung verwenden. Wir haben noch kein Veröffentlichungsdatum für Ivy.

@ocombe eine kurze Frage, wenn wir ab heute i18n (Angular6) implementieren, was verschiedene Builds (einen für jede Sprache) erfordert, geht der Aufwand verloren, wenn Ivy rauskommt und die i18n-Laufzeit? Ich meine, die Art und Weise, wie i18n jetzt implementiert würde, wird sich von dem unterscheiden, was kommt? Versuchen Sie, einige Sprints im Voraus zu planen und die Arbeit zu priorisieren. Danke

Wir wollen keine Breaking Changes erstellen, wenn wir es vermeiden können. Die IDs der extrahierten Übersetzungen können sich ändern, wenn wir Fehler beheben, die wir seit langem haben, aber wir werden ein Migrationstool anbieten. Ich kann nicht mit Sicherheit sagen, dass es zu 100% kompatibel sein wird, aber ich gehe davon aus, dass die meisten Dinge gleich funktionieren, mit neuen Optionen, die Sie verwenden können, wenn Sie möchten.

@ocombe eine kurze Frage, wenn wir ab heute i18n (Angular6) implementieren, was verschiedene Builds (einen für jede Sprache) erfordert, geht der Aufwand verloren, wenn Ivy rauskommt und die i18n-Laufzeit? Ich meine, die Art und Weise, wie i18n jetzt implementiert würde, wird sich von dem unterscheiden, was kommt? Versuchen Sie, einige Sprints im Voraus zu planen und die Arbeit zu priorisieren. Danke

Hallo, Sie können das Webpack require verwenden, um Dateien dynamisch (als temporäre Problemumgehung) mit einem Build zu laden:
Ein Beispiel finden Sie hier: https://github.com/angular/angular/issues/24549#issuecomment -402013622

Sie müssen mit --prod --aot=false bauen, da AOT=true das Webpack-Zeug entfernt.

@ocombe Hallo,

A7 Release Candidate ist da, Sollen wir wie versprochen die Runtime-Übersetzung testen?. Runtime i18n (one bundle for all locales with AOT) . Wie kann ich das testen. Bitte helfen Sie

Danke

Ich unterstütze die Frage von @sheikalthaf, obwohl v7 bereits veröffentlicht wurde.

@sheikalthaf @Shuyinsama Wie einige Kommentare oben und in der ersten Nachricht erklärt haben:
Runtime i18n erfordert ivy, das unabhängig von v7 veröffentlicht wird. Einige Teile von Ivy befinden sich bereits in v7 hinter einem Flag, aber es ist nicht vollständig und Sie sollten es nicht in einer realen Anwendung verwenden. Wir haben noch kein Veröffentlichungsdatum für Ivy.

@ocombe : Was ist mit der Übergabe des dynamischen i18n-Schlüssels von der übergeordneten an die untergeordnete Komponente?

Kindkomponente:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

Übergeordnete Komponente:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

Ich kann es übergeben, aber da die i18n-Übersetzung zur Build-Zeit erfolgt, ist die Variable in diesem Zustand noch leer. Es findet also keine Übersetzung statt.

Irgendein Update für solch einen Fall?

@bobKasbi

Sie brauchen das i18n-Tag nicht in der untergeordneten Komponente, Sie können es einfach wie folgt in der übergeordneten Komponente verwenden:

<app-input i18n-labelText="@@LabelSecondName" labelText="Second name"></app-input>

@cjsase : funktioniert super. Danke vielmals! Hatte mit fast 2 Tagen zu kämpfen.

Darauf basierend: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• Wir sollten Efeu in v7 nicht erwarten. v8 ist für März/April 2019 geplant. Wenn wir in v7 nicht mit ivy rechnen sollten, gibt es eine Empfehlung/einen Konsens darüber, was für die Internationalisierung (i18n) verwendet werden soll, bis ivy im April 2019 veröffentlicht wird?

Dies ist eine falsche Information. Das Kernteam hat nie gesagt, dass IVy 2019 veröffentlicht wird. Stattdessen sagte das Kernteam (Hervorhebung von mir):

Es sollte in jeder Nebenversion veröffentlicht werden, wenn es getestet und validiert wurde

Angenommen, ich habe eine eckige 7.1.0-beta.0-App mit aktiviertem Ivy. Ist es möglich, dass ich ein Setup mit dynamischer Sprachänderung von vorne ohne Seitenaktualisierung ausgegeben bekomme?

wenn ja wie? dieses Dokument: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
und dieses Dokument: https://angular.io/guide/i18n

hast du das nicht?

Wo kann ich lernen, wie man eine moderne/zukünftige i18n-Winkel-App erstellt?

@tatsujb nein, es ist nicht möglich, und es wird auch mit ivy & runtime i18n nicht möglich sein. Sie müssen Ihre Angular-App vorerst neu laden, wenn Sie die Sprache ändern möchten

ok, aber die Dokumentation gilt irgendwie für eine chimäre Version von eckig wie 4 minus.

Ich habe nicht das Gefühl, dass sie auf mein Setup zutreffen, noch decken sie ab, wie genau Sie die Änderung wirksam werden lassen.

Ich gehe davon aus, dass die Änderung vom Backend erzwungen werden muss.

In meinem Fall wird mein Angular im Produktionsmodus von einem Java-Spring-Backend bedient. Was sind die großen Linien dessen, was passieren wird, wenn ich auf das Flaggensymbol drücke, um die Sprache zu ändern?

Sie führen den Benutzer zu www.yourdomain.com/cn/ , wo Ihre gesamte Angular-App auf Chinesisch kompiliert wird. Am Ende haben Sie eine vollständig kompilierte Angular-App für jede Sprache, die Sie unterstützen möchten.

@ocombe @santhony7 was ist damit: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

könnte ich das versuchen?

ist es schlecht kompatibel mit 7.1.0-beta.0 oder anständig kompatibel?

@ocombe @santhony7 was ist damit: https://github.com/actra-development-oss/ng-i18n-aot-loader ?

könnte ich das versuchen?

ist es schlecht kompatibel mit 7.1.0-beta.0 oder anständig kompatibel?

Ich empfehle stattdessen die Verwendung von ngx-translate. Ich habe beide verwendet und ngx-translate ist viel einfacher zu warten.

@digismack Ein weiterer Unterschied zwischen den beiden, der etwas beängstigend ist, besteht darin, dass ngx-translate alle offiziellen Winkel-i18n-Sachen fallen lässt und überhaupt nichts davon verwendet. Es handelt sich um einen eigenen unabhängigen Schaltkreis, und die JSON-Dateien sind viel weniger spezifisch in Bezug auf die Übersetzungsquellen.

Auch von den beiden Demos scheint ngx-translate viel langsamer zu sein. Was meinen Sie damit, wenn Sie sagen, dass es einfacher zu warten war?

@tatsujb als Entwickler des ng-i18n-aot-Loaders weiß ich, dass es ziemlich schwer zu implementieren ist, zumindest die Integration der Loader.
Alles andere ist ein Kinderspiel, da es den ursprünglichen eckigen i18n-Paradigmen folgt.

Es sollte mit v7 funktionieren, solange keine wichtigen Änderungen in den Tag-Strukturen oder ähnlichem vorgenommen wurden.

Beim Versuch, ngx-translate zu implementieren, muss ich von übersetzbarem Ort zu übersetzbarem Ort gehen. Es gibt Hunderte, es ist ein bisschen lächerlich für mich, dass ich meine i18n-Tags, mit denen ich bereits im Voraus geplant hatte, nicht verwenden kann.

Ich fange an zu glauben, dass es die falsche Entscheidung war, dir zu vertrauen, @digismack

@tatsujb Es gibt 58 Personen, die diese Ausgabe verfolgen. Persönlich verfolge ich es für Updates des Angular-Teams bezüglich i18n. Ich würde es begrüßen, wenn Sie das Geschwätz stoppen würden, es sei denn, es hängt mit dem zusammen, was das OP sagt:

Wenn Sie möchten, dass neue i18n-Funktionen zu Angular hinzugefügt werden, zögern Sie nicht, unten zu fragen, und ich werde Sie wissen lassen, ob dies machbar ist und ob Sie ein Problem dafür eröffnen sollten.
Wenn Sie einen Fehler haben, öffnen Sie ein Problem (keine Notwendigkeit, hier darüber zu diskutieren).

Wenn Sie Probleme mit anderen Bibliotheken haben, schlage ich vor, eine Frage zu StackOverflow zu stellen.

Es ist nicht meine Gewohnheit, Probleme zu schreiben/kommentieren ... aber ich werde es tun!
Angesichts :
@gtbuchanan und CO sind Typ A von Person.
@tatsujb und andere Personen, die sich beschweren/kommentieren/erwarten, sind Personen vom Typ B

Typ A bist du nicht müde, immer das Gleiche zu wiederholen?!?! Für mich bist du nerviger als Typ B.

aufgrund des fehlenden i18n-features in eckig Typ B sind leute frustrierter als du, die einfach eine ausgabe "abonnieren" (wenn es darum geht, freunde zu finden, ein paar likes zu verdienen, geh auf facebook, ich weiß nicht, hier ist kein platz dafür , du wirst kein Wort ändern oder etwas erfinden, das das sagt!...)

Ich denke, Typ A kann sich abmelden, auf das Update warten, schnell das Änderungsprotokoll überprüfen oder Blogs / Nachrichten lesen. Seien Sie sicher, dass das Angle-Team es in großer Schriftart ARIAL 72pixel setzt, dass sie i18n dynamische Übersetzung von ts + Laufzeit i18n einführen: Großes Feature fehlt in Angle ! Sie haben es nicht groß in Betracht gezogen, also haben wir heute kein richtiges i18n, das ist die Strategie von Google oder so und das kann sich nicht ändern!

People B wartet auf dieses Feature vor 2 Jahren, https://github.com/angular/angular/issues/9104#issue -159302131 ja seit angle 2.X !

Ich möchte nur sagen, bitte respektiere den frustrierten Typ B und sei nicht böse. Wenn sich niemand viel über i18n beschwert, denke ich, dass eine i18n-Verbesserung in den kommenden Jahren nicht in Betracht gezogen wird, dies ist auch ein Teil von Open Source! Kritiker beschweren! Strategie kann sich ändern! Also lass die Leute sich beschweren, abmelden, du bist am besten als andere, du kannst deine Informationen finden, ohne diese Ausgabe zu abonnieren!

Typ B, bitte beschweren/kommentieren Sie weiter, bis Sie können! es ist der einzig beste Weg, die Bedürfnisse der Menschen zu verstehen!

Streik Streik lol

@tatsujb Es kommt alles auf die persönlichen Vorlieben an. Als ich ng-i18n-aot-loader das letzte Mal implementiert habe, musste ich einen ausgeworfenen Build ausführen und die Webpack-Konfiguration anpassen, damit es funktioniert. Vielleicht ist das nicht mehr der Fall. Das Ausführen eines ausgeworfenen Builds bedeutete jedoch, dass die Angular-CLI-Tools nicht mehr verwendet werden konnten. Daher fand ich es auf Dauer einfacher, ngx-translate zu implementieren und damit umzugehen, dass es etwas anders funktioniert.

@gtbuchanan Ich fühle deinen Schmerz, aber dieses "Geschwätz" steht in direktem Zusammenhang mit dem Umfang der im Beitrag von OP erwähnten Funktionen. Da der Zeitrahmen für Runtime i18n (one bundle for all locales with AOT) immer weiter gerutscht ist, kommen immer noch Leute zu diesem Thread, um nach aktuellen Lösungen zu suchen.

@ocombe , wir starten gerade ein neues Projekt, bei dem wir die Übersetzungen aus einer Datenbank beziehen.
Unsere Angular-Module werden träge geladen und wir möchten auch so nah wie möglich an dem bleiben, was Angular in Bezug auf I18N bietet.

Da es die Angular I18N-Unterstützung nicht wie geplant in die neueste Version geschafft hat - haben Sie eine Empfehlung für uns und andere, die gerade dabei sind, neue Projekte zu erstellen?

Zum Beispiel könnten wir ngx-translate verwenden, bis I18N fertig ist, aber dann habe ich irgendwo in den Github-Problemen dieses Projekts gelesen, dass es Lazy Loading nicht unterstützen wird, was für uns ein Showstopper wäre.

Andererseits ist die I18N-Unterstützung von Angular noch nicht bereit für die Hauptsendezeit.

Ich würde mich wirklich über einige Hinweise freuen, die uns in die richtige Richtung weisen, was wir für das kommende Projekt verwenden sollen - ngx-translate vs ?

Muss haben:

• faules Laden

Schön zu haben:

• ICU-Ausdrücke

Merci

Für die Follower dieser Ausgabe wird @ocombe in ein paar Stunden über die Laufzeit i18n bei angleconnect sprechen. Ich gehe davon aus, dass dort zumindest einige der offenen Fragen beantwortet werden. Es gibt einen Livestream

@ctaepper - vielen Dank für die Info!

@guygit das könnte ngx-translate oder angular-l10n sein. Hier ist die von mir erstellte Vergleichstabelle https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

Für unsere Apps haben wir uns für Angular entschieden, auch wenn es einige Einschränkungen gibt.

@fetis Vielen Dank - schaue ich mir mal an :-)

Fragen zur Auswahl von XLIFF-Dateien für die Übersetzungsdateien - Google Translate Toolkit sowie Flutter/Dart i18n unterstützen beide ARB-Dateien und unterstützen XLIFF nicht. Ich habe gehört, dass die Unterstützung von ARB-Dateien nicht geplant ist, aber ich frage mich, ob dies etwas ist, das erneut in Betracht gezogen werden könnte. Oder wenn jemand ( @ocombe ?) Aufzeigen könnte, wo Angular mit den XLIFF-Dateien interagiert, damit ich sehen kann, wie schwierig es wäre, ARB-Unterstützung zu integrieren.

(In gewissem Kontext werden wir Flutter/Dart für unsere mobilen Apps und Angular für unsere Web-App verwenden und würden unsere Übersetzungsdateien nach Möglichkeit gerne sowohl für Mobilgeräte als auch für das Web freigeben. Ich erwäge, eine zu schreiben ARB -> XLIFF-Konverter, wenn Sie keinen Appetit darauf haben, sollten Sie seine Aufnahme in Angular in Betracht ziehen.)

@localpcguy Wenn Sie am Ende einen Konverter schreiben, könnten Sie daran interessiert sein, ihn zu https://github.com/translate/translate beizutragen, das bereits die Konvertierung von/in viele Formate anbietet.

Nebenbei bemerkt, ocombe sagte vor ein paar Monaten, dass er sich stark dafür einsetzen würde, PO-Dateien (und JSON?) zu unterstützen. Hoffentlich wird es irgendwann passieren, denn wir hatten eine harte Zeit, ockay-artige Tools für die Arbeit mit XLIFF zu finden.

weil wir Schwierigkeiten hatten, ockayische Tools für die Arbeit mit XLIFF zu finden.

@PowerKiKi das stimmt einfach nicht. Fast jedes Online-Übersetzungsmanagement-Tool unterstützt das XLIFF-Format. Und es gibt sogar kostenlose Desktop-Übersetzungsprogramme, wenn Sie .xliff nicht manuell bearbeiten möchten

@fetis Ich hasse es, vom Thema abzuschweifen, habe aber ziemlich viel Schmerz in Bezug auf die Verwendung von XLIFF mit Tools festgestellt. Siehe meinen Kommentar hier: https://github.com/angular/angular/issues/20193#issuecomment -345755889

Bitte geben Sie Referenzen zu solchen Tools an, da wir immer noch nichts Gutes gefunden haben und noch etwas finden müssen, das XLIFF 2 unterstützt. Smart Cat sieht hübsch aus, aber das Aktualisieren von Strings darin lässt mich meine Augen ausmessen.

Du scheinst etwas zu wissen, was wir nicht wissen :)

Pootle verwendet https://github.com/translate/translate und war wirklich großartig mit Gettext (PO-Dateien), aber es unterstützt keine Platzhalter/Tags und sie warten auf einen Beitrag von jemandem, um es hinzuzufügen

Ich habe diese Ausgabe für ein langes Jahr oder so abonniert. Es scheint, dass Fortschritte in dieser Hinsicht keine Priorität für das Angular-Team haben, und es ist nicht akzeptabel, die App für jede Sprache einmal zu kompilieren und sich durch die Reifen zu kämpfen, um dynamische Übersetzungen durchzuführen. Ich empfehle, wenn Sie dazu in der Lage sind, eine benutzerdefinierte Pipe zu erstellen, die eine beliebige andere i18n-Bibliothek verwendet. Da diese Pipe rein ist, ist sie genauso effizient, um die App mehrmals zu kompilieren. Wenn Sie einen i18n verwenden, der nicht von Angular abhängt, können Sie auf triviale Weise dynamische Übersetzungen aus Code durchführen. Ein weiterer Vorteil ist, dass Ihre Übersetzungen nicht mehr von Angular abhängen, sodass Sie bei Bedarf mit der Migration einiger Komponenten auf andere Frameworks beginnen können, oder Sie können sogar das Übersetzungsformat und die Tools, die Sie bevorzugen, völlig frei wählen. Ich verwende https://airbnb.io/polyglot.js/ und bin sehr zufrieden damit, und selbst wenn die Migration meiner App von Angular i18n zu polyglot noch im Gange ist, kann ich mit dem Ergebnis und der Entfernung nicht zufriedener sein der Abhängigkeit mit Angular i18n.

Entschuldigung für diejenigen, die dies als Benachrichtigung in Ihrer E-Mail erhalten und sich nicht um meine Meinung kümmern, aber da ich Ihre Benachrichtigungen so lange gelesen habe, muss ich mich verabschieden, bevor Sie sich abmelden :)

Prost!

Es scheint, dass Fortschritte in dieser Hinsicht keine Priorität für das Angular-Team haben, und es ist nicht akzeptabel, die App für jede Sprache einmal zu kompilieren und sich durch die Reifen zu kämpfen, um dynamische Übersetzungen durchzuführen.

Runtime i18n hat für das Angular-Team große Priorität. Das Blockierungsproblem ist jedoch der neue Ivy-Renderer. Der Projektfortschritt ist bisher gut und wir können wahrscheinlich mit Ivy für Angular 8 rechnen. Ich verstehe, dass dies eine schwierige Situation für alle Beteiligten ist. Es gibt Pläne, aber sie können nicht umgesetzt werden, solange Ivy nicht fertig ist.

Bitte beachten Sie die Vorträge der letzten AngularConnect-Konferenz (2018) in London, insbesondere „Runtime i18n“ von Olivier Combe und die Keynote von Tag 2 von Alex Rickabaugh.

In der Tat ist meine Erfahrung ähnlich wie bei @intellix.

XLIFF 1.2 ist 10 Jahre alt , aber die Unterstützung dafür in Open-Source-Projekten scheint ziemlich schlecht zu sein. Pootle unterstützt keine Platzhalter gemäß https://github.com/translate/pootle/issues/4762 und https://github.com/translate/pootle/issues/1811. Weblate unterstützt sie auch nicht , obwohl ein PR bald Unterstützung hinzufügen könnte .

Auf dem Desktop _unterstützt Virtaal XLIFF-Platzhalter, aber die neueste Version 0.7.1 ist 6 Jahre alt und funktioniert nicht mehr auf dem neuesten macOS, wie ich gehört habe. Es macht leider nicht den Eindruck eines gepflegten Projekts, mit einigen sehr alten PR , die trotz ihrer scheinbaren Einfachheit noch darauf warten, zusammengeführt zu werden. Und eine sehr geringe Commit-Aktivität in den letzten Jahren .

Ich habe gerade herausgefunden, dass Poedit 2.2, das vor ein paar Tagen veröffentlicht wurde , XLIFF 1.2 und 2.0 unterstützt. Ich kann es leider nicht testen, da ich im Moment bei der Installation einen Fehler vom snapcraft.io CDN bekomme. Aber dies könnte die beste Lösung für Desktop-Benutzer sein.

@fetis Wenn Sie einige Open-Source-Projekte (oder zumindest kostenlose Projekte) zum Bearbeiten von XLIFF 1.2 oder noch besser XLIFF 2.0 mit Unterstützung für Platzhalter gefunden haben, listen Sie sie bitte hier auf. Alles andere, was ich getestet habe, funktionierte entweder überhaupt nicht oder war unglaublich komplex in der Anwendung.

@intellix @PowerKiKi hier ist die Liste was ich weiß. Unser Ziel ist eine Online-Übersetzungsplattform, auf der wir mit Übersetzern/Kollegen aus verschiedenen Ländern zusammenarbeiten können. Den Prozess der Installation von Desktop-Software für jeden Mitarbeiter zu durchlaufen und die Synchronisierung von XLIFF-Dateien zu verwalten, ist für uns keine Wahl. Also habe ich keine Desktop-Tools getestet, sondern Plattformen.

Anwendungen
OmegaT
https://omegat.org/

Selbst gehostet
https://weblate.org/en/ +bezahltes Hosting
https://pootle.translatehouse.org/
https://ponton.mozilla.org/

Plattformen
Crowdin
https://crowdin.com/
CLI-Unterstützung

WebTranslateIt
https://webtranslateit.com/
CLI-Unterstützung

Transifex
https://www.transifex.com/

PhraseApp
https://phraseapp.com/

Lokalisieren
https://lokalise.co/
CLI-Unterstützung

_Ich denke, wir beenden unsere Projekte mit Lokalise, da es genügend Funktionalität zu einem erschwinglichen Preis bietet._

~POEditor~
https://poeditor.com/pricing/
Die deklarierte XLIFF-Unterstützung funktioniert nicht mit dem Angular-Format

Wenn Sie nach einer Open-Source-Lösung suchen, könnte diese Liste hilfreich sein: https://opensource.com/article/17/6/open-source-localization-tools

Seitenknoten
Ich habe keine Online-Plattform gesehen, die XLIFF 2.0 unterstützt, und es war eine große Überraschung für mich. XLIFF 1.2 ist offiziell als veraltet gekennzeichnet und niemand in der Branche hat v2 unterstützt.

Ich freue mich zu hören, dass POEdit XLIFF-Unterstützung erklärt hat, ich habe es für .po-Dateien verwendet und das war nett.

PS Es tut mir sehr leid, hier ein Offtopic zu machen, aber gleichzeitig ist das Abrufen einer XLIFF-Datei aus Ihrer App nur ein Teil der Reise, Sie müssen sie übersetzen und während Ihres App-Lebenszyklus pflegen. Es ist also eine wichtige Diskussion. Ich würde vorschlagen, irgendwohin zu wechseln, ich kann diese Liste als Medium-Artikel platzieren und wir können dort weiter diskutieren.

@localpcguy Es gibt viele Formate, aber es kommt darauf an, wie viele wir unterstützen können. Das Schreiben und Warten eines Serializers nimmt Zeit in Anspruch. XLiff 2 wurde von jemand anderem als PR hinzugefügt, deshalb haben wir die Unterstützung hinzugefügt (sonst hätten wir uns nicht die Zeit genommen, es zu unterstützen).
Wir brauchen einen Serializer für zwei Dinge: Extrahieren und Zusammenführen.
Ich habe bei Angular Connect nicht darüber gesprochen, aber ich hoffe, dass wir in der Lage sein sollten, einen externen Serializer zu verwenden. Dies sollte für die Laufzeit (Merge) mit Ivy sehr einfach sein, aber die Extraktion ist immer noch kompliziert, da der Serializer aktualisiert werden muss, wenn wir Änderungen am Compiler vornehmen.
Ich habe ein paar Ideen, wie das geht, aber ich muss mit dem Team darüber sprechen, sobald Efeu landet. Was ich wirklich gerne tun würde, wäre, zumindest JSON-Unterstützung hinzuzufügen, damit ich ngx-translate mit Angular i18n umschreiben kann (und weil so viele Leute es wollen).

Danke @ocombe (und all die anderen Inputs, ich sehe gerne die verschiedenen Ansichten). Es sieht so aus, als ob #14185 der von Ihnen erwähnte PR war. Ist das immer noch ein guter Ausgangspunkt, wenn ich mir das Hinzufügen von ARB-Unterstützung ansehen möchte? Ist das etwas, das möglicherweise zusammengeführt werden könnte, wenn es eingereicht wird?

@localpcguy Wir haben morgen ein Treffen, wo wir das (und andere Dinge) besprechen werden, ich werde dich wissen lassen, wie es läuft

ok, also hier ist, was unserer Meinung nach funktionieren würde: Für die Extraktion extrahieren wir Zeichenfolgen in einer Art JSON-Format (möglicherweise sogar ARB, da es sich um ein offizielles JSON-Format für Übersetzungen handelt), das jeder nehmen und in das von Ihnen gewünschte Format nachbearbeiten kann (json ist wirklich einfach zu verwenden), und für die Laufzeit stellen wir eine Art Schnittstelle bereit, mit der Sie Ihren eigenen Loader schreiben können, der Ihr Format versteht.

Das bedeutet also so ziemlich, dass wir jedes Format für Übersetzungen verwenden können, solange wir einen Loader für die App bereitstellen können?

Das wäre doch super :+1:

Ja, Sie hätten keinen Zugriff auf tiefgreifende Optimierungen (ersetzen Sie Zeichenfolgen zur Erstellungszeit, um ein Paket pro Sprache zu erstellen, was bedeutet, dass Übersetzungen mit Ihren Komponenten in Code aufgeteilt würden), aber Sie könnten jede Art von Lazy-Loading-Lösung verwenden, die Sie wollen, solange Sie alle Übersetzungen laden, wenn die App startet (sie müssen synchron geladen werden, bevor eine Komponente erstellt wird)
Sie könnten sie auch manuell codieren und asynchron mit dem Router laden, wenn Sie eine neue Komponente laden, das liegt an Ihnen, indem Sie die neuen Lazy-Loading-Funktionen verwenden, die Ivy bietet (Jason hat eine Demo davon bei Angular Connect gemacht).

Können wir eine Beta-Demo (keine Dateien, nur ein Video oder Livestream) erwarten, um die Sprache auf Ivy im Handumdrehen zu wechseln? Der Versuch, einen POC-Efeu vor dem Finale zusammenzustellen, könnte eine großartige Möglichkeit sein, Sperrfeuer auf der ganzen Linie zu erkennen.

Nicht, dass ich mit dem Ansatz nicht einverstanden wäre, auf einen festeren Efeu zu warten, bevor ich Entwicklerschweiß in Live-i18n gieße, ich denke, dass ein kleiner Ein-Mann-POC eine kleine Menge Schweiß für eine immense Rendite in Form von ist Voraussicht und könnten möglicherweise verhindern, dass Live-i18n ins Jahr 2020 verschoben wird.

Der Laufzeitdienst für externe Benutzer ist noch nicht fertig, wir haben nur den Code, der die Schließung ( goog.getMsg ) verwendet, weil wir das brauchten, um ivy mit Google-Apps zu testen.
Daran werde ich jetzt in den kommenden Monaten arbeiten. Das bedeutet, dass Sie i18n wahrscheinlich noch nicht mit Ivy verwenden können.
Der Code für Runtime i18n wurde erst gestern zusammengeführt, und der Compiler-Code für i18n sollte in den nächsten Tagen zusammengeführt werden (wir sind am Ziel!). Dann werden wir an dem neuen Dienst für externe Leute arbeiten, einschließlich der neuen Lader, über die ich gerade gesprochen habe, und dem Dienst zur Verwendung von Übersetzungen in Ihrem Code.

Das schnelle Umschalten der Sprache erfordert immer noch ein vollständiges Neuladen der App oder möglicherweise eine Routenänderung (die alle vorhandenen Komponenten bereinigen würde). Ich würde noch nicht versuchen, an einem POC zu arbeiten.

Das schnelle Umschalten der Sprache erfordert immer noch ein vollständiges Neuladen der App oder möglicherweise eine Routenänderung (die alle vorhandenen Komponenten bereinigen würde). Ich würde noch nicht versuchen, an einem POC zu arbeiten.

das ist fair, ... erfordert jedoch kein vollständiges Neuladen der App (oder irgendetwas, das in den Augen des Endbenutzers nahtlos ist), AKA verliert weder den Speicher noch die Authentifizierung oder die URL (na ja ... ohne Berücksichtigung von /en/... ) und alles innerhalb einer angemessenen Verzögerung) ....ist immer noch der Plan, oder?

@tatsujb Das Neuladen der App lädt nicht die Seite neu, StackBlitz lädt die App bei jeder Bearbeitung neu, haben Sie das Gefühl, dass es für Ihre Augen beobachtbar ist?

Das erneute Laden der App bedeutet, dass die App unmountet und dann an derselben Position gemountet wird, was einem SSR-CSR-Übergang entspricht (es ist CSR-CSR), und es sollten keine asynchronen Aufgaben im nachfolgenden Bootstrap-Prozess vorhanden sein, wenn eine geeignete Cache-Architektur in Betracht gezogen wird.

also mit diesem richtigen Setup; Speichern von Variablenwerten und Authentifizierung (sowie Scrollbetrag bei scrollbaren Divs) würde bleiben?

@tatsujb Solange sie außerhalb der von Angular erstellten Instanz gespeichert sind, beispielsweise in einer lexikalischen Variablen oder einer Fenstereigenschaft.

@trotyl Wie lädst du die App ohne die Seite neu?

@saithis Sie booten die Anwendung immer unbedingt mit platformBootstrap().bootstrapModuleFactory() (oder einem anderen Äquivalent), Sie können sie jederzeit und überall aufrufen, es gibt keine Zauberei (außer Angular CLI hat derzeit einige Einschränkungen für die Codeersetzung, sollte nicht länger a sein Problem bei Ivy).

Bootstrap eifrig zum Zeitpunkt des Skriptaufrufs und für immer behalten (nicht unmounten) ist nur eine gängige Praxis für SPA, aber niemand zwingt Sie dazu.

BEARBEITEN: Falls jemand dies tut, ist es auch erforderlich, das Bootstrap NgModuleRef zu zerstören , um ein Speicherleck zu verhindern. Dies sind nicht zum Thema gehörende Fragen und sollten besser in einem anderen Kanal diskutiert werden, um die i18n-Diskussion hier besser zu verfolgen.

@trotyl Danke, ich wusste nicht, dass Bootstraping wieder funktioniert.

@ocombe könnten Sie bitte Spam hier entfernen? und mein kommentar auch.

1. an @fetis : Leute wie du sollten das Thema entfolgen und die Veröffentlichung abonnieren
   

2. an @Andrulko : Das ist uns egal

3. an @eckig : wie gesagt ich verstehe das meckern hier voll und ganz! wie wir wollten ivy für v7, nicht für vX oder verkaufe keine große Verbesserung für v7, während du nicht darauf reagieren konntest, oder du wirst es in 7.x einbauen, nur um deine Frist einzuhalten ... das ist nicht fair! Ja, die Option sollte sein, nichts anzukündigen, und niemand wird sich beschweren, das ist auch eine schlechte Idee, Sie müssen Ihren Platz im Rahmen schaffen. ja, wir warten auf richtige i18n seit v2, in diesem obligatorischen aspekt für große app konnte man nicht eckig verkaufen, fertig für große app wie internationale webapp, die 50000strings enthalten, natürlich magst du das nicht lesen, aber es ist ohne mitgefühl und mit gut Vertrauen, imho, wenn wir i18n und langsame Bauzeit/Entwicklungszeit für alle anderen Aspekte nicht berücksichtigen, kann ich sagen, dass eckig großartig ist. Eine bestimmte Richtung sollte sich an der Spitze ändern, ich spreche natürlich mit den Entscheidern. Hohe Ausnahme von uns (die kritisieren), weil wir von Big-Google keinen so großen Fehler machen konnten. Ich sehe Google-Entwickler als Ausnahmen – kluge Leute ohne Fehler, dies sollte erfahrenen Entwicklern und Entwicklerteams wie Google nicht passieren! Meine globale Meinung: Verkaufen Sie nicht 100% eckig für große Apps, wenn das Unternehmen sie auswählt, und verkaufen / erklären Sie dann Privatunternehmen, was Open Source ist!

4. @ alle, besonders für diejenigen, die nicht in einem Unternehmen arbeiten: mag meinen Kommentar nicht, weil ich Open Source sicherlich nicht respektiere?!?!, lol, sagen Sie dies meinem Chef, um zu warten ... zu warten ... nachdem Sie eckig gewählt haben, weil wir glauben es ist bereit (100 % nicht 80 %) für große App ... wir verlassen uns darauf!

dies ist mein letzter Kommentar hier, weil wir das Schiff verlassen! Abbestellen + Winkel in meinem nächsten Projekt nicht auswählen (man könnte sagen, Sie sind Gewinner, Open-Source-Projekte brauchen keine Leute wie uns)

Diese Leidenschaft! Nur zum Ausgleich ... wir haben unsere App in Angular 6 umgeschrieben, in 6 Sprachen internationalisiert und hatten nur geringfügige Unannehmlichkeiten. Klar, schnellere Buildzeiten und Übersetzungen im laufenden Betrieb wären sicherlich schön, aber für uns kein Weltuntergang. Die 98% des Frameworks, die nicht i18n sind, sind großartig. Tolle Arbeit Jungs! Freuen Sie sich auf neue Funktionen.

Auch für unser neues Unternehmensportal haben wir fantastische Erfahrungen mit Angular gemacht. Das i18n ist das letzte fehlende Feature, das wir brauchen, da wir in der Schweiz vier Sprachen unterstützen müssen. Ich denke, das Problem hier ist die Kommunikation. Wenn wir für die Projektplanung vor einem Jahr eine bessere Schätzung der i18-Veröffentlichung gehabt hätten, hätten wir dies planen und andere Möglichkeiten in Betracht ziehen können. Wir freuen uns jedoch über alle Neuigkeiten. :-)

Zur Verteidigung von Winkeln können Sie es einfach so in der Produktion verwenden (beste Lösung, die ich gefunden habe)

1. Übersetzten variablen Text in eine eigene Komponente einschließen, um die Übersetzungslogik irgendwohin zu verschieben

parent-component.component.html

<app-route-translation
  [routeData]="routeData"
></app-route-translation>

route-translation.component.html

<span
  i18n="route text|Navigation text for route@@routeText"
>{
  routeData.langKey, select,

  home-1 {Home 1}
  home-1-1 {Home 1-1}
  home-1-2 {Home 1-2}
  home-2 {Home 2}
  home-2-1 {Home 2-1}
  home-2-2 {Home 2-2}
  home-root {Home root}
  lazyPage {Lazy page}
  notFound {404}

  other {Other}
}</span>

1. Konfigurieren Sie Build-Konfigurationsordner wie in angle.json

"prod-en": {
  ...
   "outputPath": "dist/en/",
  ...
},
"prod-ru": {
  ...
   "outputPath": "dist/ru/",
  ...
}

1. Konfigurieren Sie die Docker-Build-Datei wie folgt, um die App für verschiedene Sprachen zu kompilieren

FROM node:8 as build-stage
WORKDIR /app
COPY angular-util .
RUN npm install
RUN npm run ng build -- --configuration=prod-en
RUN npm run ng build -- --configuration=prod-ru

FROM nginx
WORKDIR /usr/share/nginx/html
COPY --from=build-stage /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

1. Verwenden Sie diese nginx.conf, um Apps auf Subdomains bereitzustellen (z. B. en.site-name.com, ru.site-name.com), wobei ru in set $subdomain ru; durch Ihr Standardgebietsschema ersetzt werden sollte

server {
  listen 80;
  set $subdomain ru;
  if ($host ~ ^(\w+)\.) {
    set $subdomain $1;
  }
  location / {
    root /usr/share/nginx/html/$subdomain;
    try_files $uri $uri/ /index.html =404;
  }
}

Weitere Einzelheiten finden Sie hier
https://github.com/ivanivanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-shoulders-project/tree/master/container-description/ui-container-description

Für diesen Kommentar hätte ich gerne einen Daumen nach oben. Es ist vielleicht nicht perfekt, aber es ist immer noch der hilfreichste Beitrag zu diesem Thema, den ich im Internet gefunden habe

Hallo, alle miteinander,

Ich verwende i18n translations für mein Projekt. Ich habe Zweifel in folgendem Bereich:

1. Ist es möglich, verschiedene xlf-Quelldateien für verschiedene Bibliotheken zu generieren (erstellt mit dem Befehl ng generate library libraryName)?
2. Bei Verwendung der Internationalisierung für select oder pluralization erstellt die generierte xlf-Quelldatei die Trans-Unit-ID für die verschiedenen Alternativen. Ist es möglich, auch für verschiedene Alternativen eine ID über eine Vorlage bereitzustellen? (wie im Bild unten gezeigt)
   

Bitte könnt ihr mir mit ein paar Antworten helfen.

@learnersLicense :

1. Sie sollten in der Lage sein, eine Übersetzungsdatei pro Projekt zu extrahieren, das die CLI verarbeitet. Allerdings funktionieren Übersetzungen derzeit nicht mit Bibliotheken (was bedeutet, dass jemand, der Ihre Bibliothek nutzt, Ihre Übersetzungen für diese Bibliothek nicht laden kann). Es steht ganz oben auf unserer Todo-Liste für die nächsten Funktionen, die wir implementieren werden (mit Codeübersetzungen).

1. Ich glaube nicht, dass es möglich ist. Sie können Platzhalter mit speziellen Kommentaren benennen: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> , aber ich glaube nicht, dass es mit ICU-Ausdrücken funktioniert, @AndrewKushnir ?
   Sie könnten dafür eine Funktionsanfrage stellen oder vielleicht einen Kommentar zu https://github.com/angular/angular/issues/24080 hinzufügen, der ähnlich zu sein scheint (Beschreibung / Bedeutung zu ICU-Ausdrücken hinzufügen).

jemand, der Ihre Bibliothek nutzt, kann Ihre Übersetzungen für diese Bibliothek nicht laden

Eine Möglichkeit, dies zu umgehen, ist:
1) Lassen Sie die Bibliothek i18n in xliff extrahieren und übersetzen
2) Versand von xliff-Dateien mit dem Bibliothekspaket

3) Der Verbraucher extrahiert auch seine eigenen xliff-Dateien
4) Verbraucher lädt xliff in XML-Parser. löscht alle trans-Einheiten, die von node_modules stammen
5) Der Verbraucher verknüpft seine xliff mit der xliff-Bibliothek

Das bedeutet, dass jemand, der Ihre Bibliothek nutzt, Ihre Übersetzungen für diese Bibliothek nicht laden kann

Vielleicht verstehe ich diese Aussage falsch, aber ich weiß, dass die Übersetzungen für meine Firmenanwendungen beim Erstellen meiner xlf -Dateien Schlüssel enthalten, die in den Vorlagen anderer Projekte angegeben sind. Eine, die mir in den Sinn kommt, ist https://github.com/ng-bootstrap/ng-bootstrap

Dies scheint im Moment nicht möglich zu sein:

<my-button i18n-title="@@SHARED_GO_LABEL" [title]="'Go'" [button-style]="'primary'" (click)="navigateToForm()"></my-button>

Wird dies im Rahmen dieser Änderungen behoben (oder mache ich etwas falsch)?

@mikejr83

Das lässt sich machen. Sie müssen nur den Basiswert von title als title="Go" zuweisen und nicht als [title]="'Go'"

Danke @ocombe und @ewok-janitor für eure Antworten und Vorschläge. 👍

@ocombe gibt es ein vorläufiges Datum, bis wann Übersetzungen für die Bibliothek verfügbar sein könnten?

Vorerst kein Datum. Für die erste Veröffentlichung von Ivy versuchen wir nur, Feature-Parität zu erreichen. Wir werden direkt danach an den neuen Funktionen (einschließlich Codeübersetzungen und Bibliotheksunterstützung) arbeiten (oder wir beginnen tatsächlich schon vorher mit der Arbeit daran, aber es wird nicht abgeschlossen sein, wenn ivy in Alpha veröffentlicht wird). Es wird verfügbar sein, bevor Ivy zum Standard wird.

Gibt es schon einen Fix für die xliff-Dateien? https://github.com/angular/angular/issues/17506
Es ist unmöglich, das Format überhaupt zu verwenden, solange die Referenzen nicht festgelegt sind.

@ocombe Gibt es Pläne, Routenübersetzungen zu unterstützen?

Es wurde ein paar Mal angefordert, ja, es ist kein unmittelbarer Plan, aber es steht auf der Liste der Dinge, die zu tun sind

Hallo, gibt es eine Dokumentation zur Verwendung von Runtime i18n, wenn ivy in der Betaversion veröffentlicht wird?

@marcelnem , wenn Sie diese URL überprüfen, sind alle Dokumentationspunkte anhängig.

https://is-angular-ivy-ready.firebaseapp.com/#/status

@ocombe großartige Arbeit, die Sie jetzt bei Google leisten. Angular i18n hätte von Anfang an so etwas wie ngx-translate sein sollen. Ich habe mich gefragt, ob es einen Migrationsleitfaden, ein automatisiertes Tool, einen Funktionsvergleich usw. geben wird, um von ngx-translate auf den Angular i18n-Stil zu migrieren, sobald Angular 8/9 veröffentlicht wird.

Hallo Ocombe
Sie müssen sich bezüglich dieser Funktion, die Sie oben angegeben haben, mit Ihnen in Verbindung setzen
Runtime i18n (ein Bündel für alle Gebietsschemas mit AOT) - [arbeitet daran] >> Ist dies noch in Arbeit oder ist es aus

Könnten Sie mich über eventuelle Abhilfemaßnahmen informieren, falls diese noch im Gange sind
Danke

@ocombe du hast oben geschrieben, dass die Sprachpakete per Lacy Loading geladen werden sollen. Wird es auch möglich sein, die Sprachpakete direkt in die index.html zu laden? Denn wir haben den Fall, dass unsere Anwendung über AWS Lambda läuft und die kompilierten Winkeldateien in einem S3-Bucket gespeichert werden. Es ist eigentlich schon ein Workaround, dass das überhaupt funktioniert, aber wir können Lacy Loading nicht verwenden, da Angular die Dateien nicht von einem anderen Host laden kann. Daher müssen alle Dateien, die Angular benötigt, bereits in der index.html enthalten sein (wo wir den S3-Host über ein Skript hinzufügen).

@ nidhi8953 es ist immer noch WIP, es wird mit ivy verfügbar sein, im Moment funktioniert es nur innerhalb von Google (weil wir Closure Compiler intern für die Übersetzungen verwenden). Der Laufzeitdienst, der die Übersetzungen handhaben wird, ist für die Außenwelt sehr experimentell. Wenn Sie ein paar Dinge testen möchten, können Sie sich dieses Beispiel ansehen: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts , aber das sollten Sie wissen Die Funktionen sind aus einem bestimmten Grund immer noch privat, sie werden in naher Zukunft umbenannt und geändert. Das aktuelle Ziel ist es, mit der Arbeit an einem soliden Satz von APIs zu beginnen, sobald v8 herauskommt (am Ende des Monats), und dies für die gesamte v8 zu wiederholen, bis v9 herauskommt, an welchem ​​Punkt die API als stabil angesehen werden sollte

@vekunz Wenn wir unseren aktuellen Plänen folgen, sollte es möglich sein, ja, da Sie die Übersetzungsdatei sowieso beim Bootstrap Ihrer Anwendung geladen haben müssen

@ocombe Können wir Ivy (derzeit 8.0.0-rc.3) verwenden und i18n mit der Angular 7-Methode mehrerer Builds implementieren? Oder muss ich bei Angular 7 bleiben, bis die i18n-APIs für Ivy veröffentlicht werden? Wenn möglich, würde ich wirklich gerne Ivy nutzen und gleichzeitig den alten Weg von i18n verwenden, bis die neue Laufzeitmethode verfügbar ist.

Update: Nach dem Ausprobieren haben weder ng xi18n Extraktion (siehe #https://github.com/angular/angular-cli/issues/14225) noch Building w/ i18n einen Effekt. Es wird keine .xlf-Datei exportiert und es werden keine Wörter übersetzt. Aber wenn die Option enableIvy in tsconfig.app.json auf false gesetzt ist, funktionieren beide hervorragend mit Version 8.0.0-rc.3. Das bedeutet, dass ich dem Upgrade-Pfad von Angular folgen kann, i18n nicht verliere, einige der neuen Vorteile wie differenzielles Laden erhalte und bereit bin, Ivy einzuschalten, sobald i18n funktioniert.

@jacobbowdoin wie Sie herausgefunden haben, funktioniert es nicht mit eingeschaltetem Efeu, aber es funktioniert, wenn es nicht aktiviert ist.
Ich wollte das alte Extraktions-/Ladesystem mit Efeu zum Laufen bringen, aber da es nur vorübergehend gewesen wäre, wurde es vom Team nicht als Priorität festgelegt (was verständlich ist, dass die obligatorischen Dinge zuerst funktionieren, hat Priorität).

Hallo @ocombe , wir wollen jetzt den i18n entwickeln, also können wir nicht auf den Runtime-i18n warten. Würden Sie trotzdem ngx-translate empfehlen? Ist es sinnvoll, es mit i18n-polyfill zu verwenden? Erleichtert die Verwendung von i18n-polyfill die Migration zu runtime-i18n?

Wenn Sie ngx-translate verwenden, verwenden Sie nicht i18n-polyfill. Es ist nur sinnvoll, es zu verwenden, wenn Sie eckiges i18n für die Vorlagen verwenden.
ngx-translate ist immer noch relevant und einfach zu bedienen. Sie müssen nicht die gesamte Infrastruktur einrichten, um mehrere Builds (einen pro Gebietsschema) zu unterstützen.

Hallo @ocombe , gibt es ein Status-Update zu:

-Laufzeit i18n
-Verwenden Sie Übersetzungszeichenfolgen außerhalb einer Vorlage - #11405

Wir überlegen derzeit, ob wir auf Übersetzungen des Quellcodes warten oder i18n-polyfill verwenden sollten (wir haben bereits mit i18n begonnen). Wir können leicht ein paar Wochen warten, daher wäre eine ungefähre Zeitleiste wünschenswert. Danke sehr!

@halilovicedvin Sobald ivy der Standard in Google Apps ist, werden wir mit der Arbeit am Laufzeit-i18n-Dienst für externe Benutzer beginnen, also irgendwo zwischen bald und v9
Ich würde erst nach dem Sommer damit rechnen, weil die Leute einige Tage frei nehmen werden

@halilovicedvin Wir haben vor einigen Wochen mit i18n mit i18n-polyfill begonnen und es funktioniert großartig. Ich hoffe, dass runtime-i18n genauso verwendet wird wie i18n-polyfill

@vekunz Ich hatte auch gehofft, dass wir, wenn wir ngx-translate mit i18n-polyfill verwenden, einfacher zu runtime-i18n migrieren können, aber nach dem Kommentar von @ocombe (https://github.com/angular/angular/issues /16477#issuecomment-498239301) Ich bin mir nicht sicher, ob der zusätzliche Aufwand zum Einrichten des Polyfill gerechtfertigt ist. Vielleicht verwenden wir einfach ngx-translate alleine.

@vekunz , was ist deine Erfahrung mit der Einrichtung?

@marcelnem Sie können ngx-translate nicht mit i18n-polyfill verwenden. i18n-polyfill ist nur für die Verwendung mit angle-i18n vorgesehen.

Die Einrichtung von i18n-polyfill war in der Tat sehr einfach. Auch wenn die Dokumentation nicht ganz korrekt ist, habe ich sehr schnell herausgefunden, was ich ändern muss.

@vekunz jetzt verstehe ich, danke. Ich bin mir nicht sicher, was der Zweck des i18n-Polyfill ist. Muss man die App trotzdem mehrfach bauen und mehrfach unter http://myapp/en , http://myapp/de , http://myapp/fr ,... deployen wie beim offiziellen angle i18n?

@marcelnem ja, du brauchst auch mehrere Builds mit i18n-polyfill. Der Zweck ist, dass Sie mit angle-i18n Übersetzungen derzeit nur innerhalb von HTML-Vorlagen und nicht innerhalb Ihres Typoskript-Codes verwenden können. i18n-polyfill erweitert angle-i18n, um auch Übersetzungen in Ihrem Typoskript-Code zu verwenden.
Mit Angular 9 (kommt im Herbst) wird angle-i18n auch Übersetzungen innerhalb von Typoskript unterstützen, aber in der Zwischenzeit brauchen wir dafür i18n-polyfill.

@vekunz kannst du etwas genauer darauf eingehen: "Auch die Dokumentation ist nicht so ganz korrekt, ich habe sehr schnell herausgefunden, was ich ändern muss." Ich werde mich wahrscheinlich nächste Woche mit i18n-polyfill befassen, also wäre jede Information willkommen. Vielen Dank

@halilovicedvin @marcelnem Ich habe ein Pastebin-Dokument erstellt, in dem ich es beschreibe, da es nicht das Hauptthema dieser GitHub-Ausgabe ist https://pastebin.com/Xib6X6E9

@ocombe Kann ich mit dem xi18n-Tool den Eingabepfad nur auf den src-Ordner (um die Übersetzungen zu generieren) und nicht auf das gesamte Projekt/Repository beschränken?

@ocombe unterstützt Ivy mehrere Gebietsschemas mit Angular 8 (nur die Gebietsschemadefinition, keine Sprachdatei; zum Beispiel für Datumspfeifen)? Weil ein anderes Team Angular derzeit mit ngx-translate verwendet, aber eine Komponente eines Drittanbieters das richtige Gebietsschema benötigt. Eine Möglichkeit wäre, den JIT-Compiler im Prod-Modus zu verwenden, aber das ist nicht sehr schön. Sie können aber auch nicht für jede Sprache ein neues Bundle zusammenstellen, da dies zu viel wäre.

@vekunz nein, Sie können nicht mehrere Gebietsschemas festlegen, Sie müssen das Gebietsschema für jedes kompilierte Bundle festlegen (es kann in der CLI-Konfigurationsdatei festgelegt werden).
Ich weiß, es ist nicht das, was du hören wolltest, aber so ist es im Moment

@ocombe Kannst du bitte etwas sagen, ich weiß, dass das Team von Angular es nicht als Problem identifiziert, aber denkst du, dass Angular es uns in absehbarer Zeit ermöglichen wird, die Sprache zur Laufzeit zu ändern, ohne die App neu zu laden, also die Übersetzung in ein einziges Bundle und die Möglichkeit, die richtigen Übersetzungen zu laden und mit den Textliteralen zu verknüpfen?

Ein Bundle haben ja, aber die Übersetzungen müssen bei boostrap geladen werden (wenn die App geladen wird). Mit der bestehenden Architektur wäre es sehr kompliziert, die Übersetzungen "heiß" neu zu laden, ohne die Komponenten neu zu laden, die die Übersetzungen bereits verwenden.
Ich sage nicht, dass dies unmöglich ist, aber ich sehe es leider nicht in absehbarer Zeit.

Danke @ocombe für die schnelle Antwort :) Mach weiter so :+1:

Es gab irgendwo eine Präsentation von @ocombe von irgendeiner Winkelkonferenz (ich glaube AngularConnect), wo er über i18n und Ivy gesprochen hat, und dort hat er sehr gut beschrieben, warum das so kompliziert ist. Ich kann versuchen, das Video zu finden.

Ich glaube, ich habe es gefunden https://www.youtube.com/watch?v=miG-ghJhFPc

Für Leute, die auf Runtime i18n mit Ivy warten, sieht der aktuelle Plan für v9 vor, dass Übersetzungen mit Ivy funktionieren, aber nur als Build-Schritt (wie es gerade mit der View-Engine ist). Das bedeutet, dass es vorerst immer noch 1 Build / Gebietsschema sein wird und es keine Codeübersetzungen geben wird (nur Vorlagenübersetzungen).

Schade. Nun, für das, was es wert ist, danke für deine harte Arbeit!

@ocombe werden Sie weiterhin das Polyfill für Laufzeitcodeübersetzungen pflegen?

Wenn es kaputt geht, ja, werde ich aber keine neuen Sachen hinzufügen

Es ist irgendwie scheiße, dass i18n so lange ein Bürger zweiter Klasse war ... Nicht jeder arbeitet in einer Umgebung mit englischer Muttersprache. ):

Nun, ich stimme zu, ich versuche, einige Unternehmen zu finden, die mich sponsern, damit ich neue leistungsstarke i18n-Lösungen für Angular entwickeln kann (ich habe eine Menge Ideen).
Wenn Sie an interessierte Personen denken, lassen Sie es mich auf Twitter (@ocombe) oder per E-Mail ([email protected]) wissen 🙂

@ocombe Ich möchte dir auch für deine Arbeit danken. 💚 Es ist eine etwas überraschende Nachricht, dass du das Team verlassen musst. Wie Sie I had to ... gesagt haben, möchte ich Sie direkt fragen, was der Hauptgrund war. Ich hasse diese indirekten Hinweise und Vermutungen, deshalb eine so direkte Frage an Sie.

Ich war ein externer Auftragnehmer, der mit dem Angular-Team zusammengearbeitet hat, und kein Vollzeitmitarbeiter von Google. Daher kann mein Vertrag jederzeit enden, je nachdem, was das Team benötigt.
Sie rekrutieren intern neue Leute, um bei dem Projekt zu helfen, und ich bin zuversichtlich, dass sie die richtigen Leute finden werden, um bei i18n und anderen Themen zu helfen, sodass Sie sich keine Sorgen um die Zukunft von Angular machen müssen :visage_légèrement_souriant: es ist nur ein vorübergehender Rückschlag

@ocombe Danke für deine Erklärung.

Kann mir jemand sagen, wie ich i18n (i18n-polyfill) außerhalb der Klasse wie Enumerationen oder konstante Arrays oder so etwas wie .model.ts-Dateien verwenden kann?

Für Konstanten habe ich sie immer noch in eine Klasse gesteckt. Mir ist keine Alternative bekannt :/

@ocombe Vielen Dank für all Ihre harte Arbeit mit i18n für Angular mit ngx-translate, i18npolyfill und mit dem Angular-Team.
Wir verwenden Ihre Arbeit täglich, um unseren Benutzern Übersetzungen bereitzustellen, wie es für jede nicht triviale Anwendung erforderlich ist.
Viel Glück bei dem, was Sie tun, um voranzukommen.

Für Konstanten habe ich sie immer noch in eine Klasse gesteckt. Mir ist keine Alternative bekannt :/

Hmm .. wenn ich sie in die Klasse verschiebe, muss ich die Variable als statisch machen, um verwendet zu werden. Aber ich kann i18n nicht für eine statische Variable verwenden.

Exportklasse Beispiel {
Konstruktor (privat i18n: I18n) {}
statische Variable = i18n('text'); // Ich kann i18n hier nicht verwenden, da es nicht statisch von der Klasse Example ist
}

Traurige Nachrichten... das "schwächt" Angular... Wie die anderen schon sagten, bleibt nur der große Dank an @ocombe für die tolle Arbeit, viel Glück!

Ich bin neugierig, was sind die Nachteile der Verwendung von ngx-translate? Es scheint, dass es genau die Funktionalität bietet, nach der die Leute suchen

Als Nachteile würde ich sagen:

• erhöht die Bundle-Größe (externe lib + Übersetzungen als externe Dateien, anstatt den Code zur Build-Zeit zu ersetzen)
• nicht offiziell (wenn ich sterbe, wird die Bibliothek eingestellt und nicht das gleiche Maß an Unterstützung)
• unterstützt kein xliff/xmb (unterstützt aber json und andere Formate über Plugins, und man könnte ein xliff/xmb-Plugin erstellen, um es zu unterstützen)
• könnte einige fehlerhafte Verhaltensweisen haben, wenn die Übersetzungen faul geladen/aufgeteilt werden (ich musste das nie beheben)
• Die Syntax ist im Vergleich zur offiziellen Implementierung komplizierter
• Leistung (das anfängliche Laden der Übersetzungen kann den Text für 1s verschwinden lassen, und mehr Speicherdruck, weil ich den Inhalt zur Laufzeit überwachen muss, um zu sehen, ob sich etwas geändert hat)

Davon abgesehen scheint es für viele Leute gut genug zu sein 🙂

Es ist merkwürdig, wie eckig Barrierefreiheit fördert und in diese investiert, aber keine Sprachen in diesem Paket enthält. Es scheint wirklich, dass dies eine Entscheidung ist, die aus einer einsprachigen Umgebung heraus getroffen wurde.

Da ich aus einer Umgebung komme, in der wir normalerweise 3-4 Sprachen abwechselnd bedienen müssen, habe ich geduldig auf die Veröffentlichung dieser Funktion gewartet, seit sie angekündigt wurde, mit ihren klaren Vorteilen gegenüber der Verwendung einer externen Bibliothek. Mit diesen Neuigkeiten muss ich unsere Strategie zur Verwaltung von Übersetzungen komplett überdenken.

@ocombe Keine Chance, dass Google dich nicht als Auftragnehmer einstellt?😉

@DmitryEfimenko Wir verwenden derzeit ngx-translate und sind sehr zufrieden damit.

@ocombe Wie hoch ist die Wahrscheinlichkeit, dass Google diese Funktion von externen Entwicklern/Community akzeptiert? Ich glaube, wir warten zu lange.

Wenn Sie es ernst meinen und Zeit damit verbringen möchten, daran zu arbeiten, dann würde ich sagen, dass die Chancen hoch sind, dass sie Hilfe annehmen, um an diesem Feature zu arbeiten

Wenn Sie es ernst meinen und Zeit damit verbringen möchten, daran zu arbeiten, dann würde ich sagen, dass die Chancen hoch sind, dass sie Hilfe annehmen, um an diesem Feature zu arbeiten

@ocombe @IgorMinar Ich würde gerne etwas Freiwilligenarbeit für Ivy i18n leisten, bitte lassen Sie es mich wissen, wenn es Möglichkeiten gibt.

Wenn Sie es ernst meinen und Zeit damit verbringen möchten, daran zu arbeiten, dann würde ich sagen, dass die Chancen hoch sind, dass sie Hilfe annehmen, um an diesem Feature zu arbeiten

Ich bin bereit, mich einzubringen, aber ich kenne den Umfang und die Komplexität der Aufgaben absolut nicht. Können wir die Liste in der ursprünglichen Nachricht als unsere Spezifikation/Anforderungen nehmen?

Nein, diese Liste ist jetzt veraltet.
Ich werde das Team wissen lassen, dass Sie beide interessiert sind, damit wir sehen können, wie wir das organisieren können.

@ocombe Ich denke, es sind mehr als 2 von uns.

Was wir von den Angular-Teams brauchen, sind

• eine Anforderungsliste/eine Spezifikation
• Grobe Komplexitätsschätzung
• 1-2 Mentoren für die Kommunikation

mit dieser Community könnte die Entwicklung organisiert und Aufgaben aufgeteilt werden

Mir ist auf https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q?view etwas bekannt

@fetis Es ist möglicherweise keine gute Idee, die Arbeit zu stark aufzuteilen, die Kommunikation und das Teilen des Kontexts kosten ebenfalls viel, insbesondere bei einigen Kernarbeiten mit hoher Wahrscheinlichkeit von Konflikten.

Immer noch überrascht, dass XLIFF als Pro aufgeführt wird (oder besser gesagt, das Fehlen davon für ngx-translate ist ein Contra). Google Translate und andere Google-Dienste scheinen ARB-Dateien zu verwenden, bei denen es sich um eine JSON-Darstellung von Übersetzungszeichenfolgen handelt. Zum Beispiel haben wir unsere mobilen Apps mit Flutter/Dart gebaut, wo die INTL mit ARB-Dateien implementiert ist. Es wäre schön, wenn das Angular-Team dies bei der Überprüfung berücksichtigen würde, um eine bessere Zusammenarbeit mit anderen Elementen im Google-Ökosystem zu ermöglichen.

Es ist möglicherweise keine gute Idee, die Arbeit zu sehr aufzuteilen, denn Kommunikation und gemeinsame Nutzung des Kontexts kosten ebenfalls viel Geld, insbesondere bei einigen Kernarbeiten, bei denen ein hohes Konfliktrisiko besteht.

Ich stimme zu, aber ich glaube nicht, dass das Ganze von einer Person in einer angemessenen Zeit geliefert werden kann. Der Umfang ist zu groß

Es ist möglicherweise keine gute Idee, die Arbeit zu sehr aufzuteilen, denn Kommunikation und gemeinsame Nutzung des Kontexts kosten ebenfalls viel Geld, insbesondere bei einigen Kernarbeiten, bei denen ein hohes Konfliktrisiko besteht.

Ich stimme zu, aber ich glaube nicht, dass das Ganze von einer Person in einer angemessenen Zeit geliefert werden kann. Der Umfang ist zu groß

@fetis Ich kann mit dir arbeiten. Wir möchten wirklich eckiges i18n in unseren Projekten verwenden, aber es ist sehr begrenzt.

Ich werde das Team wissen lassen, dass Sie beide interessiert sind, damit wir sehen können, wie wir das organisieren können.

@ocombe irgendwelche Rückmeldungen vom Angular-Team?

Ich habe sie informiert und sie schienen interessiert zu sein, aber sie müssen einen konkreten Plan für all das haben, bevor sie externe Hilfe annehmen können (sonst werden Sie wahrscheinlich nicht an dem arbeiten, was benötigt wird).
@petebacondarwin übernimmt ab sofort

Hallo @ocombe , ich habe die Kommentare durchgesehen und ungefähr verstanden, dass es immer noch keine Bestimmung gibt, dynamische IDs für das i18n-Tag zu erstellen, während wir sie in *ngFor verwenden. Gibt es eine andere Möglichkeit oder Problemumgehung? Oder ich muss nur mit ngx-translate gehen.

@swapnilvaidankar Ich glaube nicht, dass es eine Problemumgehung gibt, nein

@swapnilvaidankar - kannst du erklären, was du damit meinst?

Erstellen Sie dynamische IDs für das i18n-Tag, während wir sie in *ngFor verwenden

Wie wir wissen, müssen wir, um den statischen Text in eine andere Sprache zu übersetzen, das i18n-Attribut im HTML-Element-Tag wie unten verwenden,

<h1 i18n = "Card Header | Title for the under construction card@@constructionheader">Under Construction</h1>

Dadurch wird das xlf-Datei-Snippet wie folgt generiert, und wir können das Ziel für jede Sprache festlegen. Hier habe ich für Französisch wie folgt übersetzt,

  <trans-unit id="constructionheader" datatype="html">
    <source>Under Construction</source>
    <target>En construction</target>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/app.component.html</context>
      <context context-type="linenumber">3</context>
    </context-group>
    <note priority="1" from="description"> Title for the under construction card</note>
    <note priority="1" from="meaning">Card Header </note>
  </trans-unit>

Aber im Falle einer Dropdown-Liste scheint es schwierig zu sein, das i18n-Attribut zu verwenden.
Wenn ich beispielsweise die Liste der Produkte wie Visitenkarten, Flyer und Broschüren in einer Dropdown-Liste oder einer einfachen Liste anzeigen möchte, wie kann ich die dynamische ID für die generierenTag daher kann ich die Produktnamen ins Französische oder jede andere Sprache übersetzen.

Ich habe es auf diese Weise versucht,

• 
  {{ Produkt }}
  

was das xlf-Datei-Snippet wie unten generiert und nicht sicher ist, wie es verwendet werden soll, um den Produktnamen in andere Sprachen zu übersetzenSchild

  <trans-unit id="product" datatype="html">
    <source><x id="INTERPOLATION" equiv-text="{{ product }}"/></source>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/product/product.component.html</context>
      <context context-type="linenumber">6</context>
    </context-group>
    <note priority="1" from="description"> product name from List</note>
    <note priority="1" from="meaning">product name </note>
  </trans-unit>

Das Problem hier, wenn Sie die ID in sehen könnentag ist nur 'produkt'. Ich hatte jedoch erwartet, dass die IDs dynamisch generiert werden sollten, da die Liste der Produkte in der Dropdown-Liste verfügbar sein wird.

Sie sind sich nicht sicher, wie Sie dies erreichen können, wenn Sie mit dynamischen Inhalten oder Inhaltslisten arbeiten.

Sorry für die umfangreiche Erklärung.
Ich hoffe, Sie haben das Problem hier verstanden.

Danke,
Swapnil

Kannst du dazu bitte ein Thema eröffnen? Es ist hier nicht wirklich das Thema und wenn jemand anderes danach sucht, wird es einfacher sein, es zu finden

@swapnilvaidankar i18n-Attribute sind für die statische Textübersetzung gedacht, nicht für dynamische Inhalte. In Ihrem Beispiel stammen "Produkte" entweder aus Ihrem Quellcode (sind in Ihrer ts-Datei definiert) und Sie müssen ngx-translate verwenden (oder haben übersetzte Produktnamen direkt in der ts-Datei) oder stammen von einer HTTP-Anfrage dann sollten übersetzte Produktnamen von Ihrem Backend bereitgestellt werden.

Ich glaube nicht, dass wir dafür ein neues Thema brauchen. Es ist nur eine Anfrage nach Laufzeitübersetzungen in TS-Dateien, die bereits viele Male angefordert wurde.

@swapnilvaidankar Wenn die Anzahl der Optionen begrenzt ist und Sie es bereits wissen, können Sie eine Komponente mit einfachem ngSwitch erstellen, die den Text rendert. Wir verwenden diese Problemumgehung, funktioniert wie ein Zauber.

@fetis - das Problem ist, dass diese allgemeinen Themen sehr leicht in Diskussionen über bestimmte Dinge abgelenkt werden können. Das Erstellen eines neuen Problems bietet einen neuen Thread, um diese Diskussion fortzusetzen, ohne diese abzulenken.

@fetis Ja, dieses Problem habe ich viele Male an vielen Orten gesehen, aber ich habe keine richtige Lösung gefunden. Ich bin auch auf ngSwitch gestoßen, aber in meinem Fall keine geeignete Lösung. Trotzdem danke für die Problemumgehung.

@ocombe Ich glaube, ich muss dies als Problem irgendwo anders posten, um dasselbe zu diskutieren, als hier. 👍

Vielen Dank für die Antworten.

@petebacondarwin @swapnilvaidankar hier ist das Problem https://github.com/angular/angular/issues/11405 , nach dem Sie suchen
seit 2.0.0-rc.6 (!) übrigens

Hallo @ocombe , ist diese Ausgabe noch aktuell? Scheint, als würde Ivy die Standardeinstellung für Angular 9 sein, also frage ich mich, wie der Status von i18n ist. Können Sie bitte abschätzen, wann es produktionsbereit sein könnte? Mit Winkel 9, 10, 11? Wenn nicht mit Angular 9, wird Angular 9 (und Ivy) ohne i18n ausgeliefert oder wird es das alte i18n verwenden?

Weitere Informationen zum aktuellen Stand finden Sie in dieser (https://github.com/angular/angular/issues/11405) Ausgabe. Lesenswerte Kommentare in dieser Ausgabe zum aktuellen Stand:

• https://github.com/angular/angular/issues/16477#issuecomment -512290696
• https://github.com/angular/angular/issues/16477#issuecomment -506378004
• https://github.com/angular/angular/issues/16477#issuecomment -512548506

Auch das ist einen Besuch wert.

Obwohl wir den Schalter in v9 umlegen, sodass standardmäßig ivy verwendet wird, gehen wir davon aus, dass es möglicherweise eine Reihe von Szenarien gibt, die nicht vollständig funktionieren, und dass diese Projekte vorerst bei der View-Engine bleiben würden.
Wir arbeiten daran, i18n für die Version v9.0.0 zum Laufen zu bringen, aber es wird eng.

Welcher aktuelle Stand zu "Runtime i18n (ein Bundle für alle Locales)"?

@Ivajkin - Entschuldigung, dass dieses Problem nicht auf dem neuesten Stand gehalten wird.

„Runtime i18n“ ist ein häufig gefragtes Feature, kann aber für verschiedene Personen unterschiedliche Bedeutungen haben.
Im neuen i18n $localize -Ansatz wird es möglich sein, die eigentliche Übersetzung zur Laufzeit durchzuführen.

Die Laufzeit kann tatsächlich ziemlich kompliziert sein, wenn Sie nicht nur alle möglichen Nachrichten übersetzen, bevor die Angular-Anwendung bootet. Wenn Sie dies tun, dann könnte der neue Ansatz zur Kompilierzeitübersetzung genau das sein, was Sie brauchen.

Im neuen i18n erfolgt die Übersetzung ganz am Ende Ihrer Build-Pipeline – nicht im Angular-Compiler – das bedeutet, dass Sie in der Lage sein sollten, unübersetzte Nachrichten in Bibliotheken usw. bereitzustellen und die Übersetzung nur dann vorzunehmen, wenn Sie die endgültige Anwendung erstellen.

Das ist alles in Arbeit für v9.0.0.

Sehen Sie sich https://github.com/angular/angular/tree/master/packages/localize an, um zu sehen, wo wir sind.

@petebacondarwin Würde es Ihnen etwas ausmachen, die neue Übersetzung zur Kompilierungszeit ein wenig zu erläutern? Wird uns dies ermöglichen, ein einzelnes Paket (mit AOT) zu erstellen, das für alle Gebietsschemata funktioniert?

Anstatt die Übersetzung innerhalb des Angular-Compilers durchzuführen, „taggen“ wir bei dem neuen Ansatz einfach die Nachrichten, die übersetzt werden müssen, über einen globalen $localize - Template-String-Tag-Handler . Diese getaggten Zeichenfolgen überdauern alle Arten von Bündelung und Verkleinerung, sodass sie am Ende Ihrer Build-Pipeline immer noch vorhanden und auffindbar sind. Diese Dateien könnten das Bündel Ihrer Bibliothek sein, das Sie an ein anderes Team senden, um es in dessen Bewerbung aufzunehmen!

Wir haben jetzt ein paar Optionen:

a) Führen Sie ein Tool aus, das diese markierten Nachrichten statisch identifiziert und durch Übersetzungen ersetzt. Dadurch werden die $localize -Referenzen effektiv aus dem JavaScript entfernt und Sie erhalten ein minimales Codepaket für die Verteilung. Dieses „Compile Time Inlining“-Tool kann eine Reihe von Übersetzungen übernehmen und eine Kopie Ihres Pakets für jede Sprache, die Sie übersetzen, erstellen. Da es ganz am Ende Ihrer Build-Pipeline ausgeführt werden kann, müssen Sie keine anderen Aspekte Ihres Builds für jede unterstützte Sprache ausführen.

b) Ermöglichen Sie den $localize -Tags, in den Code zu gelangen, der im Browser ausgeführt wird, und verwenden Sie eine Implementierung von $localize , um die Nachrichten zur Laufzeit zu übersetzen. Der Nachteil dieses Ansatzes besteht darin, dass die Nutzlast für den Browser größer ist, da er die $localize -Aufrufe, aber auch die $localize -Übersetzungsimplementierung enthalten muss. Außerdem müssen Sie die Übersetzungen selbst an den Browser senden. Ein Vorteil dieses Ansatzes könnte darin bestehen, Lazy Loading von Übersetzungen zur Laufzeit zu unterstützen. Aber es ist fraglich, ob die Übersetzung auf dem http-Server (oder Build-Server) eine effizientere Laufzeiterfahrung macht.

Laufzeitoption b) bitte. Wir könnten Übersetzungen als JSON-Dateien laden und zur Laufzeit die Sprache wechseln, wie wir es derzeit mit ngx-translate tun.

Danke für die Erklärung. Ich verstehe, dass der Ansatz a) eher "eckig" ist, aber der große Vorteil des Ansatzes b) (und Lazy Loading im Allgemeinen) ist auch die Möglichkeit, Übersetzungen dynamisch durch Benutzer zu definieren / zu ändern (modifizierte Übersetzungen für Apps könnten sofort verwendet werden). . Wenn ich es richtig verstehe, würde jede kleine Änderung in der Übersetzung in Ansatz a) einen Neuaufbau bedeuten.

Dies ist der gleiche Vorteil wie der Wechsel von statisch generierten Seiten mit vordefinierten Angular-Komponenten zu benutzergenerierten Vorlagen enthält die vom Programmierer definierten Angular-Komponenten wie vom Benutzer gewünscht (die so definierte Vorlage würde auch aus der Datenbank geladen werden ... )

Möglicherweise haben Sie auch über die Möglichkeit nachgedacht, dass beim Laden standardmäßig der Ansatz a) verwendet wird. Wenn eine Übersetzungsanfrage zur Laufzeit auftritt (z. B. beginnt das Backend mit dem Senden neuerer Übersetzungen), werden die markierten Blöcke (die bisher statischen Text enthielten) mit dem Crawlen und dynamischen Ersetzen wie im b)-Ansatz begonnen. So würde b) nur bei Bedarf aktiviert und alle übersetzbaren Teile werden gemäß Verfahren a) vorbereitet. Ich verstehe, dass ein solcher Ansatz aufwändiger wäre als der b)-Ansatz selbst und auf diese Weise sicherlich nicht direkt durchführbar wäre, aber dies würde den tatsächlichen Bedürfnissen der Benutzer näher kommen.

Zu den von Ihnen aufgeführten Optionen bin ich bereit, in bestimmten Fällen etwa 25% der Anwendungsleistung zu opfern, um eine solche dynamische Funktionalität zu erreichen (natürlich würde ich diesen dynamischen Ansatz nicht überall verwenden). Wenn also die lokalisierte AOT-Vorlage in 0,4 Sekunden gerendert würde, im Fall einer dynamischen Vorlage, wenn sie in 0,5 Sekunden generiert würde, würde ich sie immer noch als akzeptabel in Apps betrachten, in denen ich solche sofortigen Reaktionen auf Übersetzungsänderungen benötige.

@demisx beide Ansätze werden mit v9 verfügbar sein, aber nur Option a) wird zunächst vollständig unterstützt (aus Gründen der Retrokompatibilität), neue Dinge könnten für Option b) entwickelt werden, bevor sie vom Angular-Team vollständig unterstützt werden.
Meine Bibliothek Locl wird ein paar Helfer für Option b) bereitstellen, wenn v9 veröffentlicht wird, damit jeder sie verwenden kann, bis das Angular-Team diese Lücke schließt

Beachten Sie, dass eine solche Laufzeitübersetzung nicht "reaktiv" in dem Sinne wäre, dass es nach dem Rendern einer Komponente nicht möglich wäre, ihren Text dynamisch zu ändern, selbst wenn eine neue Übersetzung geladen würde.

Übersetzte Nachrichten sind in Bezug auf mit $localize markierte Zeichenfolgen statisch. Die Komponente müsste also neu gerendert werden. Und je nach Zwischenspeicherung von Templates in IVY kann es sein, dass ein erneutes Rendern nicht einmal ausreicht.

Dies ist einer der Gründe, warum die Laufzeitübersetzung schwierig zu implementieren ist, da ihr Verhalten nicht unbedingt intuitiv wäre.

In Bezug auf den hybriden Ansatz, mit einer statischen Übersetzung im Build zu beginnen und dann später eine Laufzeitübersetzung hinzuzufügen. Dies könnte machbar sein, wenn das Inlining zur Kompilierungszeit die $localize -Tags nicht entfernt, sondern nur die vorlagenbasierten String-Literalteile aktualisiert. Dies würde jedoch zu den Kosten für die Kompilierzeit plus den zusätzlichen Kosten für die Paketgröße führen.

Wenn Sie ng xi18n auf Angular 9 RC1 ausführen, wird "Es tut uns leid, aber i18n ist noch nicht in Ivy implementiert" zurückgegeben, aber das Änderungsprotokoll zeigt an, dass jetzt _etwas_ i18n-Unterstützung implementiert ist. Ich nehme an, die Übersetzungsdateien müssen vorerst manuell aktualisiert werden?

@neil-119 Derzeit wird die Extraktion im Efeu-Modus nicht unterstützt. Sie müssen Ivy noch deaktivieren, um die Extraktion auszuführen. Aber dann können Sie es wieder aktivieren, um die extrahierten Übersetzungsdateien zu verwenden.

Ich hoffe, es ist geplant, die Extraktion in die endgültige v9-Version aufzunehmen.

@neil-119 Angular CLI sollte VE automatisch zum Extrahieren verwenden. Sie müssen nichts tun, damit das funktioniert. Wir testen das auch, also bin ich überrascht, dass es kaputt ist. Kannst du bitte ein Thema mit Repro eröffnen?

Derzeit wird die Extraktion im Efeu-Modus nicht unterstützt.

oder nein, es ist ein Show-Stopper. Derzeit haben wir einen automatisierten Prozess mit Zeichenfolgenextraktion. Wie können wir zu Ivy migrieren, wenn wir Übersetzungen nicht automatisch extrahieren können?
sconfig.json every time manipulieren? Das klingt nicht gut für mich.

@fetis - ich habe mich geirrt. Wenn Sie CLI verwenden, sollte der Aufruf ng xi18n wie erwartet funktionieren, auch wenn ivy aktiviert ist.

@petebacondarwin danke. Ich werde Ivy in unseren aktuellen Projekten ausprobieren, also hoffe ich, dass ich dies bald bestätigen kann

Hallo, ich habe versucht, in meiner Komponente (Winkel 9.0.0-rc.1) zu verwenden

$localize `some string to localize`;

gefunden als doc im Quellcode von @angular/localize/init.

Wenn ich versuche, wie gewohnt für meine Sprache zu bauen, erhalte ich diesen Fehler
No translation found for "4145296873012977836" ("some string to localize").

Wie kann ich eine Übersetzung für diese Zeichenfolge bereitstellen?
Ich erwarte, dass ng xi18n die .xlf-Datei auch mit diesem Text aus dem Komponentencode generiert. Ist es richtig oder fehlt mir etwas?

Hallo @Ks89 - Das Extrahieren von Nachrichten aus dem Anwendungscode (anstelle von Vorlagen) wird für v9 nicht unterstützt.
Aber Sie können das umgehen, wenn Sie hinterhältig sind. 4145296873012977836 ist die ID der Nachricht. Wenn Sie also eine Übersetzung in Ihrer Übersetzungsdatei mit dieser ID bereitstellen, wird sie beim Übersetzen verwendet.

@petebacondarwin, wann wird diese Funktion zu Angular hinzugefügt?
Ich denke, dass es wirklich wichtig ist, Laufzeitübersetzungen in Komponenten wirklich nützlich zu machen.

Wenn ich meine .xlf-Datei an einen Übersetzer sende, erwarte ich, alle Zeichenfolgen schnell hinzuzufügen und das Ergebnis dann sehr einfach auf die App anzuwenden.

Danke für die Antwort

Ich würde es in 9.1 erwarten

Wenn wir eine Möglichkeit haben, die gesamte App neu zu rendern, egal was ChangeDetectionStrategy für jede Komponente ist, dann ist es so einfach, diese dynamischen Probleme zu lösen.

@petebacondarwin Angular 9 wird jetzt mit der neuen $localize-Tag-Funktion veröffentlicht, jedoch ohne Extraktion der Nachrichten. Sie sagten zuvor, dass wir dies in Angular 9.1 erwarten könnten. Ist diese Prognose immer noch gültig und können wir davon ausgehen, dass die $localize-API stabil ist?

Sie können Übersetzungen aus Vorlagen extrahieren.
Wenn Sie auch $localize in Ihrem Code verwenden möchten, sollten Sie einen Blick auf Locl werfen: https://github.com/loclapp/locl/
@locl/cli können Sie aus Code und Vorlagen extrahieren

@vekunz - die Prognose ist immer noch gültig. Wie @ocombe betont , funktioniert der aktuelle CLI-Übersetzungsextraktionsmechanismus außerdem gut für jede Übersetzung, die sich in einer Angular-Vorlage befindet (dh Dinge, die durch die i18n -Tags gekennzeichnet sind). Das Einzige, was Sie derzeit mit den Kernwerkzeugen nicht extrahieren können, sind Aufrufe von $localize innerhalb Ihres eigenen Codes (z. B. in einem Dienst oder einer Komponente).

Der Aufruf $localize selbst ist eine stabile API.

Die Tools, die Übersetzungen und Extraktionen (insbesondere zur Kompilierzeit) durchführen, sind immer noch nicht öffentlich. Dies ist jedoch kein Problem, es sei denn, Sie planen, Ihre eigenen Werkzeuge darum herum zu bauen (wie es @ocombe bei Locl tut!).

Danke @petebacondarwin , damit konnten wir die Texte aus dem Code in eine "versteckte" Komponentenvorlage zur Extraktion duplizieren. Dann sollten sowohl die Extraktion als auch die Übersetzung funktionieren, oder?

@ocombe Mit der Prognose, dass die Extraktion mit Angular 9.1 funktioniert, würde unser Manager nicht für Ihre Lösung bezahlen. Vor allem, weil wir keine Live-Umschaltung von Sprachen und übersetzten Routen benötigen.

Wir könnten die Texte aus dem Code in eine „versteckte“ Komponentenvorlage zum Extrahieren duplizieren

Ja, diese Problemumgehung würde vorerst funktionieren.

Ich bin verwirrt: Wird die Laufzeitübersetzung auch in 9.1 möglich sein? Oder nur das Extrahieren außerhalb von Vorlagen? Oder nichts davon?

Für mich wären die Laufzeitübersetzungen ein Killer-Feature. Mehrere Bundles bereitzustellen und den Benutzer zu zwingen, die gesamte Seite neu zu laden, ist meiner Meinung nach keine gute Benutzerfreundlichkeit.

@JustDoItSascha
Ich habe eine einfache Demo erstellt, die die Laufzeitübersetzung demonstriert.
https://stackblitz.com/edit/ivy-vjqzd9?file=src%2Fapp%2Fapp.component.ts

Hallo! Ich versuche, loadTranslations in main.ts aufzurufen, weil Strings übersetzt werden, während JavaScript Importe analysiert, aber das reicht nicht aus.

main.ts importiert AppModule, das AppComponent importiert (wobei ich $localize verwende).

Damit es funktioniert, mache ich:

loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule);

Dies funktioniert jetzt, führt jedoch dazu, dass das "complier.js"-Bundle von Angular in das Anbieter-Bundle aufgenommen wird.

Irgendeine Möglichkeit, das zu vermeiden? Danke

Derzeit muss loadTranslations aufgerufen werden, bevor die Anwendung gestartet wird, sodass dies in polyfills.ts erfolgen kann. Und wenn Sie einen anderen Satz von Übersetzungen laden möchten, müssen Sie die Seite neu laden. Wenn Sie ein bisschen mehr verstehen möchten, warum, habe ich https://blog.ninja-squad.com/2019/12/10/angular-localize/ geschrieben, um es zu erklären.

Derzeit muss loadTranslations aufgerufen werden, bevor die Anwendung gestartet wird, sodass dies in polyfills.ts erfolgen kann.

Es ist sogar noch schlimmer, es muss aufgerufen werden, bevor eine Moduldatei importiert wird, deshalb funktioniert es, wenn Sie es in polyfills.ts einfügen (das vor der Haupt-App-Datei ausgeführt wird), aber wenn Sie es in Ihrer verwenden möchten "main"-Datei, dann müssen Sie ein dynamisches import(...) für das Modul verwenden

@vekunz , es ist ein guter Grund, meine Bibliothek vorerst nicht zu verwenden 😊 Da es bei Locl nicht nur um die Extraktion geht, beabsichtige ich, viele andere Tools hinzuzufügen, um i18n zu vereinfachen

Besteht die Absicht, die Laufzeit i18n jemals in Angular zu implementieren? Wir haben das Feature fast drei Jahre lang erwartet und jetzt ist Ivy da und es ist immer noch nur halb ausgereift.

Besteht die Absicht, die Laufzeit i18n jemals in Angular zu implementieren? Wir haben das Feature fast drei Jahre lang erwartet und jetzt ist Ivy da und es ist immer noch nur halb ausgereift.

Mein Verständnis ist, dass Ivy in vielerlei Hinsicht ein Wegbereiter für kommende Dinge ist. Es überrascht nicht, dass sich die i18n-Nadel mit der Veröffentlichung von Ivy unglaublich bewegt hat, aber sie sollte das Potenzial für große Veränderungen in der Zukunft freisetzen. Das war meine Lektüre davon und meine Hoffnung jedenfalls.

@Karasuni - Ich denke, wir müssen klären, was die Laufzeitübersetzung tatsächlich für das Kern-Angular-Framework bedeutet, da darüber ziemlich viel Verwirrung herrscht.

Die Änderungen, die wir für v9 vorgenommen haben, betreffen die $localize basierende Übersetzung. Das primäre Ziel dabei war, die Übersetzung vom Angular-Compiler zu entkoppeln, sodass eine Reihe netter Verbesserungen möglich sind:

Die erste davon, die allen Benutzern von v9 sofort zur Verfügung steht, besteht darin, die Generierung übersetzter Anwendungen zu beschleunigen. Bisher musste die gesamte Build-Pipeline für jede Sprache ausgeführt werden, in die Sie Ihre App übersetzen wollten. Jetzt muss die Hauptkompilierung Ihrer Anwendung nur einmal ausgeführt werden, und der endgültige Übersetzungsprozess, der erheblich kürzer ist, wird für jede Sprache auf der Ausgabe des Builds ausgeführt. Um dies zu unterstützen, gibt es das neue @angular/localize -Paket, Änderungen im Angular-Compiler und eine ganze Menge Arbeit in der Angular-CLI, um dies so nahtlos und transparent wie möglich zu gestalten

Zweitens, da die $localize -Tags im verteilten Code belassen werden können, ist es jetzt auch möglich, die Übersetzung im Browser durchzuführen (zur Laufzeit statt zur Kompilierzeit). Das verstehen wir im Core-Angular-Framework als Laufzeitübersetzung. Aber bitte beachten Sie, dass das Endergebnis davon effektiv dasselbe ist wie die Übersetzung zur Kompilierzeit. Die Übersetzung erfolgt nur einmal; wenn Sie die Sprache zur Laufzeit ändern möchten, müssen Sie die gesamte Anwendung neu starten (z. B. durch ein Reload). Dies hat den Vorteil, dass das Projekt eine einzige verteilbare Datei mit zahlreichen Übersetzungsdateien bereitstellen kann, was in einer kleinen Anzahl von Anwendungsfällen hilfreich ist, in denen Sie nicht alle verschiedenen Übersetzungen im Voraus generieren möchten. Es gibt einige knifflige Probleme beim rechtzeitigen Laden der Übersetzungen, wie von @ocombe und anderen hier hervorgehoben. Sie können https://www.locl.app/ für weitere Hilfe dazu in Betracht ziehen.

Beachten Sie, dass diese "Laufzeit"-Übersetzung auch auf Lazy Loaded-Routen verwendet werden kann, sodass es möglich sein kann, je nach Einrichtung unterschiedliche Routen in verschiedenen Sprachen zu haben.

Da es keinen einzigen Ansatz für dieses Laden von Übersetzungen gibt, der für alle Szenarien funktioniert, haben wir dies noch nicht in die CLI gebacken oder stabile öffentliche APIs bereitgestellt, um dies zu unterstützen. Sobald wir die Anwendungsfälle besser verstehen, können wir möglicherweise mehr Unterstützung dafür hinzufügen. In der Zwischenzeit könnten Dinge wie Locl helfen, wenn Sie es nicht wagen wollen, es selbst zu erarbeiten.

Beachten Sie schließlich, dass das dynamische Ändern von übersetzten Zeichenfolgen zur Laufzeit vom Angular-Kernframework ausdrücklich nicht unterstützt wird (designbedingt). Das Einhängen der übersetzten Strings in das Änderungserkennungssystem von Angular würde die meisten Anwendungen zu sehr belasten und die Leistung ruinieren. Aus meinen Interaktionen mit der Community habe ich kaum reale Szenarien gesehen, in denen dies tatsächlich erforderlich ist, abgesehen vom Neustart der Anwendung bei Sprachänderungen. Wenn dies eine Anforderung für Ihre Anwendung ist, können Sie dies erreichen, indem Sie eine speziell angefertigte Pipe für Ihre Zeichenfolgen in Vorlagen verwenden, die Übersetzungen einzieht und vielleicht sogar $localize spontan zum Übersetzen aufruft, aber es sieht nicht so aus das wäre sehr performant. Andernfalls könnten Sie einen dynamischeren Ansatz wie https://netbasal.gitbook.io/transloco/ in Betracht ziehen.

Die wichtigsten Änderungen in der nächsten Nebenversion von Angular werden eine verbesserte Übersetzungsextraktion sein, die in der Lage sein wird, lokalisierte Zeichenfolgen aus TS-Code zu identifizieren und zu extrahieren – derzeit verarbeitet die CLI-Extraktion nur lokalisierte Zeichenfolgen in Vorlagen.

Änderungen zur Verbesserung der Laufzeitübersetzung, wie oben beschrieben, würden frühestens nach 9.1 erscheinen.

Beachten Sie schließlich, dass das dynamische Ändern von übersetzten Zeichenfolgen zur Laufzeit vom Angular-Kernframework ausdrücklich nicht unterstützt wird (designbedingt). Das Einhängen der übersetzten Strings in das Änderungserkennungssystem von Angular würde die meisten Anwendungen zu sehr belasten und die Leistung ruinieren. Aus meinen Interaktionen mit der Community habe ich kaum reale Szenarien gesehen, in denen dies tatsächlich erforderlich ist, abgesehen vom Neustart der Anwendung bei Sprachänderungen.

Ich kann mich irren, aber allein in diesem Thread zeigten viele Leute ausdrücklich Interesse an der Möglichkeit, die Sprache live zur Laufzeit zu ändern, ohne die Anwendung neu erstellen oder neu laden zu müssen. Oder hat jeder hier eine andere Definition von runtime translation ?

Ich möchte eine Anwendung nicht neu laden, nur um eine Sprache zu wechseln. Wenn sich ein Benutzer beispielsweise auf einer Seite mit einem Formular befindet, wird das Neuladen einer ganzen Seite für einen Übersetzungswechsel für den Benutzer irritierend sein.

Nur um es klar auszudrücken. Was ich sagen wollte, ist, dass viele Leute zu mir gekommen sind, um zu sagen, dass sie unbedingt eine Live-Sprachänderung in ihrer Anwendung benötigen. Aber wenn Sie sich mit den Gründen befassen, stellt sich heraus, dass dies nicht der Fall ist. Ich sage nicht, dass es keine Szenarien gibt, die dies erfordern, aber nach meiner Erfahrung im letzten Jahr sind mir nur sehr wenige begegnet.

Frage: Warum sollte ein Benutzer die Sprache wechseln müssen, wenn er zu einem bestimmten Formular in Ihrer App geht?

Ich denke auch nicht, dass eine Live-Schaltung erforderlich ist. Wie oft ändern Sie die Sprache einer Website? Normalerweise höchstens einmal. Und für dieses eine Mal ist ein Seitenneuladen nicht so kritisch. Wie @petebacondarwin sagte, sind fast alle Szenarien für die Live-Schaltung keine relevanten realen Szenarien, sondern nur „nice to have“.

Oder hat jeder hier eine andere Definition von Laufzeitübersetzung?

Ich brauche unbedingt Laufzeitübersetzungen. Unsere Kunden müssen in der Lage sein, Übersetzungen vor Ort zu bearbeiten und zu aktualisieren, nicht nur auf dem Build-Server. Also Laufzeit, im Gegensatz zur Kompilierzeit.

Das tatsächliche Umschalten der Sprache nach dem Laden der Seite ist ein nettes Extra.

Nur um es klar auszudrücken. Was ich sagen wollte, ist, dass viele Leute zu mir gekommen sind, um zu sagen, dass sie unbedingt eine Live-Sprachänderung in ihrer Anwendung benötigen. Aber wenn Sie sich mit den Gründen befassen, stellt sich heraus, dass dies nicht der Fall ist. Ich sage nicht, dass es keine Szenarien gibt, die dies erfordern, aber nach meiner Erfahrung im letzten Jahr sind mir nur sehr wenige begegnet.

Frage: Warum sollte ein Benutzer die Sprache wechseln müssen, wenn er zu einem bestimmten Formular in Ihrer App geht?

Sie könnten Recht haben, dass dies keine solide Anforderung ist. Ich könnte versuchen, Übersetzungen beim Laden bereitzustellen, aber es wird die Benutzererfahrung der Anwendungen, die derzeit in der Lage sind, die Sprache dynamisch zu wechseln – ohne Neuladen oder Ändern der Position auf der Seite – mit einer externen Bibliothek vollständig verändern. Übersetzungen sind seit langem ein heißes Thema.

Ich habe eine wichtige Frage: Können Übersetzungsdateien asynchron geladen werden? Alle meine Übersetzungen werden in einer Datenbank gespeichert, da es wichtig ist, sie ohne Neuaufbau aktualisieren zu können.

Ja, sie können asynchron geladen werden, aber Sie müssen den Start Ihrer Anwendung verzögern, bis sie geladen wurden

Nur um es klar auszudrücken. Was ich sagen wollte, ist, dass viele Leute zu mir gekommen sind, um zu sagen, dass sie unbedingt eine Live-Sprachänderung in ihrer Anwendung benötigen. Aber wenn Sie sich mit den Gründen befassen, stellt sich heraus, dass dies nicht der Fall ist. Ich sage nicht, dass es keine Szenarien gibt, die dies erfordern, aber nach meiner Erfahrung im letzten Jahr sind mir nur sehr wenige begegnet.
Frage: Warum sollte ein Benutzer die Sprache wechseln müssen, wenn er zu einem bestimmten Formular in Ihrer App geht?

Sie könnten Recht haben, dass dies keine solide Anforderung ist. Ich könnte versuchen, Übersetzungen beim Laden bereitzustellen, aber es wird die Benutzererfahrung der Anwendungen, die derzeit in der Lage sind, die Sprache dynamisch zu wechseln – ohne Neuladen oder Ändern der Position auf der Seite – mit einer externen Bibliothek vollständig verändern. Übersetzungen sind seit langem ein heißes Thema.

Technisch gesehen können Sie die gesamte App neu laden und den Benutzer trotzdem dort halten, wo er war.
Sie benötigen "nur" eine zustandsgesteuerte App (mit ngxs, ngrx oder einer anderen Zustandsverwaltungsbibliothek), die irgendwo gespeichert und beim Start abgerufen wird.

Der einzige Trick wäre, die Bildlaufposition beizubehalten, aber das ist auch machbar.

@petebacondarwin Ich muss sagen, dass ich dir zustimme. Ich kenne keine echten Endbenutzer (außer Testern in der Entwicklungsphase), die eine App bei der Verwendung dauerhaft zwischen den Sprachen wechseln. Sicher, sie tun es wahrscheinlich am Anfang, wenn sie es irgendwie in einem anderen öffnen, aber später ist es ein seltener Fall.

Oder hat jeder hier eine andere Definition von Laufzeitübersetzung?

Ich brauche unbedingt Laufzeitübersetzungen. Unsere Kunden müssen in der Lage sein, Übersetzungen vor Ort zu bearbeiten und zu aktualisieren, nicht nur auf dem Build-Server. Also Laufzeit, im Gegensatz zur Kompilierzeit.

Das tatsächliche Umschalten der Sprache nach dem Laden der Seite ist ein nettes Extra.

Ich bin mir nicht sicher, was Ihre Kunden tun, aber "Übersetzungen live auf der Produktionswebsite bearbeiten" klingt nicht nach einem alltäglichen Szenario.

Ich sehe das Wechseln der Sprache live (_ohne Neuladen der Seite_) nicht als solchen Deal Breaker an.
Das Ändern einer Sprache für einen Benutzer erfolgt nur einmal;

Denken Sie darüber nach, wie oft haben Sie Ihre Telefonsprache geändert? wahrscheinlich einmal oder Sie haben einfach mit der Standardsprache gerollt.

Das Beobachten von Sprachänderungen, um Live-Änderungen ohne Neuladen der Seite vorzunehmen, bringt eine Menge Leistungseinbußen für etwas mit sich, das für die Lebensdauer eines Benutzers kaum verwendet wird.

Letztendlich kommt es für mich auf 3 Dinge an;

1. Extrahieren Sie Übersetzungen aus Vorlagen und TS-Dateien.
   
   
   
   • Quell-Lang-Asset aktualisieren.
   
   
   • Auch die Übersetzung aktualisieren (_wenn ich mehrere Sprachen habe, fr, en, de... Ich möchte, dass alle mit neuen und entfernten Übersetzungsschlüsseln aktualisiert werden._)
   
   
2. Ein Build für alle Übersetzungen (_Es ist auch in Ordnung, 1 Build für jede Übersetzung zu haben, solange es die Build-Zeit nicht vervielfacht._)
3. Abrufen verfügbarer Sprachen und Ändern der Sprache mit Neuladen.

@Karasuni
Sie können Übersetzungen asynchron abrufen und erst dann die Winkel-App laden.
Siehe meinen Kommentar oben zum asynchronen Laden des app.module mit import(...) .

Persönlich benutze ich Wikipedia, um herauszufinden, in was der Titel eines Films, den ich kenne, in eine andere Sprache "übersetzt" wurde.

in der heutigen Zeit ist es mehr als alltäglich, zwei- oder dreisprachig zu sein (außer innerhalb der USA, nicht böse gemeint).

Der Benutzer möchte möglicherweise die Sprache wechseln, es ist völlig plausibel. Das Wikipedia-Beispiel ist ein positives Ergebnis, dies ermöglicht zu haben. Ich sehe nicht ein, warum wir andere potenzielle Anwendungen unter dem Vorwand der Leistung ersticken sollten, bevor sie das Licht der Welt erblicken.

sogar ngx-translate von ocombe, das für euch das gleichbedeutende beispiel für "schlechte übersetzungen" sein muss, lief für den alltäglichen benutzer perfekt schnell genug.

Ich persönlich bin dreisprachig und kann mich nicht auf eine Sprache festlegen: Alle Sprachen sind für mich schön

Bei allem Gesagten kann ich dem nicht zustimmen:

Denken Sie darüber nach, wie oft haben Sie Ihre Telefonsprache geändert? wahrscheinlich einmal oder Sie haben einfach mit der Standardsprache gerollt.

Wikipedia ist dafür das schlechteste Beispiel, denn die verschiedenen Sprachen eines Artikels sind eigentlich eigenständige Artikel. Normalerweise brauchen Sie nicht verschiedene Sprachen auf der gleichen Seite. Auch wenn Sie viersprachig arbeiten.
Und wenn Sie tatsächlich eine Live-Schaltung benötigen, können Sie entweder den Workaround mit der benutzerdefinierten Übersetzungspipe verwenden, die @petebacondarwin erwähnt hat, oder das neue Tool von @ocombe.

OK, also denke ich nicht, dass dies wirklich der beste Ort ist, um diese Diskussion zu führen. Ich mache mir Sorgen, dass wir (obwohl bisher alle sehr vernünftig waren) in eine negative Diskussion geraten könnten. Ich befürchte, dass das Angular-Framework auf absehbare Zeit keine sofort einsatzbereite Lösung für die Live-Sprachumschaltung bieten wird.

Ich habe das Gefühl, dass der Wert dieses Themas seinen Lauf genommen hat. Ich habe die offenen Probleme und PRs, die in der Beschreibung dieses Problems verlinkt sind, nach https://github.com/angular/angular/milestone/101 verschoben und werde diese PR schließen und sperren.

Wenn Sie neue Probleme mit Funktionsanfragen haben, öffnen Sie bitte ein neues Problem und markieren Sie mich darin.