Lokalisierung

[rakader]

Ich habe früher mit iLocalize 4 immer mal wieder ein Progrämmchen lokalisiert, um dessen Benutzung in einem kleinen Team zu vereinfachen oder Lokalisierungsfehler zu beseitigen. Seit nib und xib - also schon seit geraumer Zeit - geht das ja nicht mehr. Der Vorteil von iLocalize gegenüber xCode war klar: Ein schlankes GUI ohne verwirrende Zwischenschritte, gerade für einen Nutzer, der außer AppleScript, HTML und ein wenig PHP sonst nicht viel mit Programmieren am Hut hat

Gibt es heute ein ähnliches Programm wie iLocalize, um nachträglich Lokalisierungen anzufertigen?
Wenn nein, gibt es eine leicht verständliche Anleitung, wie man das in xCode umsetzt? Was ich bisher zu xCode gelesen habe, hat mich frühzeitig aussteigen lassen. Ich war nicht einmal in der Lage ein Übersetzungsprojekt überhaupt zu öffnen.

Danke vorab für Eure geduldigen Hinweise.

 

[MacApple]

Gibt es heute ein ähnliches Programm wie iLocalize, um nachträglich Lokalisierungen anzufertigen?

Du willst fertig kompilierte Programme lokalisieren? Das dürfte schwierig werden, denn jede Änderung am Programmbundle bricht die Signatur. Folge: das Programm wird vom Betriebssystem nicht mehr ausgeführt, außer die Programme sind sowieso nicht signiert.

 

[Bountyhunter]

Wer es braucht - hilft das hier ?

https://de.wikipedia.org/wiki/Computerunterstützte_Übersetzung

 

[MacApple]

Hinzu kommt, das die Interface-Dateien inzwischen auch „kompiliert“ werden und daher auch nicht mehr wie früher, einfach zu bearbeiten sind.

 

[Bountyhunter]

Das wird ihm klar sein, und wenn er es braucht....

 

[rakader]

Vielen Dank Euch. Sehe, das wird in den meisten Fällen nichts, eben wegen kompilierter Interface-Dateien.
In manchen Fällen geht es doch/noch - da hilft mir der Verweis auf Wikipedia. PoEdit setze ich bei Wordpress ein, da bleibe ich dabei. Und ein Sprach.lproj-Ordner mit entsprechenden strings-Dateien ist schnell angelegt.

Im aktuellen Fall macht mir hoffentlich die Signatur keinen Strich durch die Rechnung - es geht um die Übersetzung der Hilfe. Beim anderen Fall handelt es sich um Backup-Dateien, die auf Audio-Hardware rücküberspielt wird.

 

[Marcel Bresink]

Du willst fertig kompilierte Programme lokalisieren? Das dürfte schwierig werden, denn jede Änderung am Programmbundle bricht die Signatur.

Das stimmt so nicht. Sprachpakete dürfen jederzeit hinzugefügt oder entfernt werden, wenn bestimmte Grundregeln eingehalten werden. Die Signaturtechnik ist ausdrücklich so konstruiert, dass das erlaubt ist.

Hinzu kommt, das die Interface-Dateien inzwischen auch „kompiliert“ werden und daher auch nicht mehr wie früher, einfach zu bearbeiten sind.

Bei modernen Programmen ist das aber nicht mehr nötig. Programme, die für OS X 10.8 oder höher konzipiert sind, sollten eigentlich nur noch die Techniken "Auto Layout" und "Base Localization" verwenden. Wenn das zutrifft, braucht man für eine Übersetzung die Interface-Dateien nicht mehr zu berühren.

 

[MacApple]

Das stimmt so nicht. Sprachpakete dürfen jederzeit hinzugefügt oder entfernt werden, wenn bestimmte Grundregeln eingehalten werden. Die Signaturtechnik ist ausdrücklich so konstruiert, dass das erlaubt ist.

Ok.
Edit: Ich habe noch mal in der Dokumentation geschaut und folgendes gefunden:

Resource Rules
Systems before OS X Mavericks 10.9 documented a signing feature (--resource-rules) to control which files in a bundle should be sealed by a code signature. This feature has been obsoleted for Mavericks. Code signatures made in Mavericks and later always seal all files in a bundle; there is no need to specify this explicitly any more. This also means that the Code Signing Resource Rules Path build setting in Xcode should no longer be used and should be left blank.

It is thus no longer possible to exclude parts of a bundle from the signature. Bundles should be treated as read-only once they have been signed.​

Das klingt für mich doch eher danach, dass auch Lokalisierungen die Signatur brechen.

Bei modernen Programmen ist das aber nicht mehr nötig. Programme, die für OS X 10.8 oder höher konzipiert sind, sollten eigentlich nur noch die Techniken "Auto Layout" und "Base Localization" verwenden. Wenn das zutrifft, braucht man für eine Übersetzung die Interface-Dateien nicht mehr zu berühren.

Na ja, es wäre schon hilfreich die Strings erst einmal auszulesen. Alle Strings manuell abzulesen ist doch sehr mühsam.

 

[Marcel Bresink]

Das klingt für mich doch eher danach, dass auch Lokalisierungen die Signatur brechen.

Nein, das war noch nie so. Der zitierte Abschnitt bezieht sich darauf, neben den Lokalisierungen noch weitere Resourcen von der Signaturprüfung auszuschließen, ändert aber an dem Grundsatz nichts. Seit Sierra gibt es zwar ein Problem bei der Prüfung von Bundles mit verschachtelten Signaturen (signierte Bundles mit eigener Lokalisierung innerhalb von signierten Bundles), aber das ist ein Bug.

Na ja, es wäre schon hilfreich die Strings erst einmal auszulesen.

Das ist nicht nötig. Wenn die modernen Techniken genutzt werden, liegen alle Strings bereits fein säuberlich in ".strings"-Dateien vor. Es reicht, einen lproj-Ordner zu duplizieren und in der Kopie alle Strings zu überschreiben. Kann man zur Not mit TextEdit machen. Es sind keinerlei Entwicklerwerkzeuge erforderlich.

 

[MacApple]

Der zitierte Abschnitt bezieht sich darauf, neben den Lokalisierungen noch weitere Resourcen von der Signaturprüfung auszuschließen

Alles klar. Finde ich dann aber missverständlich geschrieben. Die Lokalisierungen liegen ja nun mal auch im App-Bundle.

Wenn die modernen Techniken genutzt werden, liegen alle Strings bereits fein säuberlich in ".strings"-Dateien vor.

Das setzt voraus, dass das Programm für Lokalisierung vorbereitet ist. In nicht lokalisierten Programmen findet man oft noch nicht einmal den Base.lproj Ordner und selbst wenn es den gibt, heisst das noch nicht, dass es für die Interfacedateien schon ".strings" Dateien gibt.