Lokalisierung

Dieses Thema im Forum "macOS-Developer" wurde erstellt von rakader, 01.02.17.

  1. rakader

    rakader Pomme au Mors

    Dabei seit:
    29.10.06
    Beiträge:
    872
    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.
     
  2. MacApple

    MacApple Schmalzprinz

    Dabei seit:
    05.01.04
    Beiträge:
    3.578
    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.
     
  3. Bountyhunter

    Bountyhunter Linsenhofener Sämling

    Dabei seit:
    15.04.09
    Beiträge:
    2.516
  4. MacApple

    MacApple Schmalzprinz

    Dabei seit:
    05.01.04
    Beiträge:
    3.578
    Hinzu kommt, das die Interface-Dateien inzwischen auch „kompiliert“ werden und daher auch nicht mehr wie früher, einfach zu bearbeiten sind.
     
  5. Bountyhunter

    Bountyhunter Linsenhofener Sämling

    Dabei seit:
    15.04.09
    Beiträge:
    2.516
    Das wird ihm klar sein, und wenn er es braucht....
     
  6. rakader

    rakader Pomme au Mors

    Dabei seit:
    29.10.06
    Beiträge:
    872
    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.
     
    #6 rakader, 02.02.17
    Zuletzt bearbeitet: 02.02.17
  7. Marcel Bresink

    Marcel Bresink Safran Pepping

    Dabei seit:
    28.05.04
    Beiträge:
    4.354
    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.

    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.
     
  8. MacApple

    MacApple Schmalzprinz

    Dabei seit:
    05.01.04
    Beiträge:
    3.578
    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.

    Na ja, es wäre schon hilfreich die Strings erst einmal auszulesen. Alle Strings manuell abzulesen ist doch sehr mühsam.
     
    #8 MacApple, 03.02.17
    Zuletzt bearbeitet: 03.02.17
  9. Marcel Bresink

    Marcel Bresink Safran Pepping

    Dabei seit:
    28.05.04
    Beiträge:
    4.354
    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.

    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.
     
  10. MacApple

    MacApple Schmalzprinz

    Dabei seit:
    05.01.04
    Beiträge:
    3.578
    Alles klar. Finde ich dann aber missverständlich geschrieben. Die Lokalisierungen liegen ja nun mal auch im App-Bundle.
    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.