Translation

[metaxy]

How shall we translate?

[axtho]

Ich denke, dass sie OneSky etabliert hat, oder? Theo hatte bestimm auch wegen den Strings gesprochen, die jeder für sich dann neu definieren kann. D.h. wir könnten einen Satz an übersetzten Strings liefern (per OneSky), und der Gemeinde/Verein/... die Möglichkeit bieten diese für sich noch einmal zu definieren (z.B. heißt es nun Gemeinde oder Versammlung? Mitglied oder ...).

Wollen wir das in einer Tabelle führen oder das in eine Datei schreiben, welche dann das jeweilige Standardlabel überschreibt (eine Art inheritance)?

[metaxy]

Darüber habe ich auch noch nicht so nachgedacht. Man müsste sie schon in der DB speichern und dann aus der DB auch verwenden. Aber es wäre schon cool, wenn es mit den normalen i18n strings verbunden wäre. Vielleicht onthefly die i18n strings mit denen aus der db aktualisieren?

[metaxy]

https://angular.io/docs/ts/latest/cookbook/i18n.html

[axtho]

Sieht gut aus :) ... nur wie bekommen wir das mit den Texten hin, wie oben beschrieben? Im Grunde müsste man für jedes aktualisierte label die .xlf Datei neu generieren?

[metaxy]

https://medium.com/@feloy/deploying-an-i18n-angular-app-with-angular-cli-fc788f17e358#.sasop4nww

https://github.com/angular/angular-cli/issues/2201

[axtho]

https://support.oneskyapp.com/hc/en-us/articles/205978508-File-formats-that-OneSky-supports

[axtho]

aber ... ich sehe nicht, wie wir es dann schaffen, dass man die Platzhalter als Gemeinde neu definieren kann, ohne die .xlf Datei zu überschreiben

depends on #12

[metaxy]

This Angular-cli is completely not ready for working with it...

https://github.com/angular/angular-cli/issues/3674#issuecomment-268859663

[axtho]

another way is possible: use interpolated strings: write a label Provider that loads the strings from the API once on signup and injects the labels in the templates and components.

This would require some sort of cashing to not have to load on each request. This way we could include the user defined strings in the backend easier (use changes a label for himself -> write to backend -> read out std translations and replace the label with the user translation -> fetch new translation strings -> cache)

[axtho]

Until Angular's i18n is production ready we will use a combination of i18n and a self-written service that will serve: a) the user definable strings (there won't be that many) b) the strings we use in-code (e.g. "Error in saving to notes"). See example here.

There is much discussion going on around this issue. You can track this here, here and these articles: here and here

The approach will therefore be twofold: build and bundle the current language for the church at ng build --aot --prod and have the service load and interpolate labels that can be changed (or those in .ts files).

Possible ALTERNATIVE: is to use ng2-translate (here). It gives you the option to extend the loader service. There we could (somehow) intercept strings that should be fetched from API and leave the rest as usual).

WHY NOT USE ng2-translate from scratch?

• version 6 is just out and has some issues
• AOT compilation is still a problem

We'll revisit in a while, since our string base is still small enough to change at a later point

[axtho]

using the build-in i18n now for everything and waiting on Ang4 to be able to translate string from TS (likely from 4.3 onward)

[axtho]

So TS translation will only be ready for Ang5, see here.

The first Beta for v5 should be out mid June, see here.