String format validation

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • String format validation

    Hallo allerseits,

    gibt es ein tool oder habt ihr sowas selbst geschrieben um string formate zu validieren.
    Es geht vor allem um die Lokalisierung.

    Ich habe zb das Englsiche Ausgangsformat:

    "Downloaded %d files from %@"

    hat also zwei parameter, erster ein integer, zweiter ein objekt.
    Jetzt möchte ich alle lokalisierungen überprüfen dass zb keiner der folgenden fehler enthalten ist:

    "Downloaded %@ files from %@" (also zwei objekte)

    oder

    "Downloaded %2$d files from %1$@" (erster parameter müsste objekt sein, zweiter integer - ist aber umgekehrt)

    eventuell noch weitere fehler die mir im moment nicht einfallen...

  • Wenn ich @gritsch richtig verstehe, möchte er sicherstellen, dass in allen Lokalisierungs-Dateien alle Strings mit den richtigen Parametern aufgeführt sind.

    Da es auch die Möglichkeit gibt, die Position der Parameter je nach Sprache zu verändern, klingt es für mich schon nach etwas Parsen:
    • Für jeden String in der "Stamm-Datei" die unterschiedlichen Parametertypen und deren Häufigkeit ermitteln
    • Nun in jeder Lokalisierungs-Datei den String suchen und parsen, bei Fehlen bzw. Abweichungen der Häufigkeiten einen Fehler auswerfen.
    Wenn jemand so etwas hat oder schreibt, hätte ich auch Interesse. Das schreit nahezu nach einem kleinen CLI-Tool ... wenn mir nur etwas langweilig wäre :D

    Mattes

    Edit: Wenn jetzt im Verwürfelungsfall noch im Code auf die Richtigkeit der Parameter-Reihenfolge geprüft werden soll, wird's tricky...
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()

  • Ich habe mir abgewöhnt in die Localisierungs-Texte irgendwelche Parameter zu schreiben. Macht alleine schon das Übersetzen schwerer da manchmal aus dem Text heraus gar nicht hervorgeht wofür der Parameter jetzt eigentlich steht.
    Ich schreibe alle meine Texte so:

    Downloaded @@@ACTUALCOUNT@@@ files from @@@TOTALCOUNT@@@

    Damit ist mit einem kurzen Satz jedem Übersetzer erklärt was mit diesen Tokens zu tun ist. Für mich bedeuetet das halt kurz die Token wieder programmatisch zu ersetzen aber ein strreplace ist jetzt auch nicht so der riesen Aufwand.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • MyMattes schrieb:


    Edit: Wenn jetzt im Verwürfelungsfall noch im Code auf die Richtigkeit der Parameter-Reihenfolge geprüft werden soll, wird's tricky...

    Die Reihenfolge der Parameter hängt aber doch von der Zielsprache ab. Das kann man doch gar nicht durch einen Vergleich mit der Quellsprache auf Korrektheit überprüfen.

    Ein etwas an den Haaren herbeigezogenes Beispiel (mir fällt spontan nichts besseres ein):

    Deutsch: ein Drittel == 1/3
    Japanisch: ３分の１（さんぶんのいち = sanbun no ichi）
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    MyMattes schrieb:

    Edit: Wenn jetzt im Verwürfelungsfall noch im Code auf die Richtigkeit der Parameter-Reihenfolge geprüft werden soll, wird's tricky...
    Die Reihenfolge der Parameter hängt aber doch von der Zielsprache ab. Das kann man doch gar nicht durch einen Vergleich mit der Quellsprache auf Korrektheit überprüfen.

    Ein etwas an den Haaren herbeigezogenes Beispiel (mir fällt spontan nichts besseres ein):

    Deutsch: ein Drittel == 1/3
    Japanisch: ３分の１（さんぶんのいち = sanbun no ichi）
    Ein Grund warum ich nur mit Strings als Parametern arbeite.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Schon klar, daher müsste dann im Quelltext geprüft werden, ob %1$@ zumindest den richtigen Variablentyp zugewiesen bekommt ... inhaltliche Prüfung ist kaum möglich, nur formale.

    Andererseits muss m. E. eine App eh in jeder Zielsprache getestet werden, so dass fehlerhafte Lokalisierungsstrings dabei auffallen ... und ja keine Prüfung zur Laufzeit erfordern.

    Claus' Ansatz gefällt mir sehr gut, da er die Ersetzung "sprechend" macht.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Hallo,

    ich hatte das Problem auch schon öfters.
    Gerade bei komplizierteren Texten, also nicht nur Labels kann das schnell umständlich werden.

    Deshalb habe ich mir entsprechende Methoden gebaut, um ein NSDictionary zu übergeben.
    D.h. in dem Grundtext wird nach dem/den Schlüssel/n geschaut und durch die Werte ersetzt.

    Das hat sich bei Erklärungen und Mehrfachaufkommen von gleichen Parametern als nützlich gezeigt.

    "Es sind %@ Dateien markiert. Wenn Du die %@ Dateien löschst, dann werden…".
    Statt der %@ setze ich {-files count-} ein und das kann je nach Sprache unterschiedlich oft sein.

    Entsprechende Plural/Singular Probleme habe ich mit [-s-] etc. gelöst.
    Das ist natürlich nicht für jede Sprache möglich.

    Aber da nahezu nur für Deutsch und Englisch lokalisiere habe ich mit dem Muster kein Problem.

    Nur mal so als Ansatz…

    Viele Grüße

  • macmoonshine schrieb:

    torquato schrieb:

    Ein etwas an den Haaren herbeigezogenes Beispiel (mir fällt spontan nichts besseres ein):
    Im Gegensatz zu Europa nennt man in sehr vielen anderen Ländern den Familiennamen vor dem Rufnamen. ;)
    Gar kein schlechtes Beispiel. Ich habe wohl zu sehr an Zahlen gedacht.

    Auch das von mir erwähnte Japanisch gehört dazu. Ja sogar in unserer eigenen Sprache gibt es Regionen, in denen das Usus ist. Im Südtitolerischen z.B. hört man regelmäßig Sachen wie "Der Kofler (,der) Christoph".

    Was in Sachen Familiennamen noch viel 'schlimmer' ist: Es gibt Länder/ Kulturen, die haben gar keinen Familiennamen in unserem Sinne!

    Darf ich vorstellen:
    "Das ist Herr Johansson und seine Schwester Frau Johansdotir."
    "Herr Nabokov und Frau Nabokova."

    In Ländern wie Burma/ Myanmar geht's komplett gegen jeglichen Strich. Das müßte ich nochmal nachlesen...

    Grausam wirds, wenn eine Deutsche Frau, in derem Ausweiß 'Erika Schmidt, geb. Müller' steht, in Japan heiratet und dann zwangsweise dort in den Papieren als 'Erika Tanaka-Schmidt geb.' geführt wird. Kein Schwein kümmert sich auf internationaler Ebene um solche 'Lappalien'...

    Lokalisierung hat auch seine persönlichen Höhen und Tiefen... :)
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Grausam wirds, wenn eine Deutsche Frau, in derem Ausweiß 'Erika Schmidt, geb. Müller' steht, in Japan heiratet und dann zwangsweise dort in den Papieren als 'Erika Tanaka-Schmidt geb.' geführt wird. Kein Schwein kümmert sich auf internationaler Ebene um solche 'Lappalien'...

    Warum solte sie zwei mal heiraten bzw beim zweiten mal legt sie den nachnamen des ersten ehemannes (Schmidt) doch wieder ab :)

  • macmoonshine schrieb:

    Im Gegensatz zu Europa nennt man in sehr vielen anderen Ländern den Familiennamen vor dem Rufnamen.
    Bin ja in einer Usa-Firma angestellt und wir reden uns immer mit Vornamen an. Also nicht nur hier in D. sondern weltweit. Dementsprechend sind auch unsere Namenslisten sortiert. Etwas gewöhnungsbedürftig wenn man gewohnt ist immer weit unten zu stehen und auf einmal ist man in der Mitte.

    Thallius schrieb:

    Downloaded @@@ACTUALCOUNT@@@ files from @@@TOTALCOUNT@@@

    Damit ist mit einem kurzen Satz jedem Übersetzer erklärt was mit diesen Tokens zu tun ist. Für mich bedeuetet das halt kurz die Token wieder programmatisch zu ersetzen aber ein strreplace ist jetzt auch nicht so der riesen Aufwand.
    Könnte man sicherlich auch schön mit einem Shell-Skript machen und vor dem Kompilieren aufrufen lassen. Man hat sein Input-file und daraus wird eine Output-file mit Hilfe von sed generiert. Output-file sollte auch nur dann generiert werden, wenn der Timestamp beider Dateien unterschiedlich ist bzw. Output-file gar ned existiert.

  • Thallius schrieb:

    Ich habe mir abgewöhnt in die Localisierungs-Texte irgendwelche Parameter zu schreiben. Macht alleine schon das Übersetzen schwerer da manchmal aus dem Text heraus gar nicht hervorgeht wofür der Parameter jetzt eigentlich steht.
    Ich schreibe alle meine Texte so:

    Downloaded @@@ACTUALCOUNT@@@ files from @@@TOTALCOUNT@@@

    Damit ist mit einem kurzen Satz jedem Übersetzer erklärt was mit diesen Tokens zu tun ist. Für mich bedeuetet das halt kurz die Token wieder programmatisch zu ersetzen aber ein strreplace ist jetzt auch nicht so der riesen Aufwand.

    Gruß

    Claus

    um den kontext zu haben kann man ja einen kommentar angeben der zb ein beispiel enthällt.

    auch in dem fall gibt es das gleiche fehlerpotential denn wer garantiert dir dass die übersetzer die keys korrekt einsetzen?

    dann musst du noch zuerst jeden wert in einen string umwandeln und zusätzlich für jeden einen sprechenden namen definieren. dann wieder ersetzen etc...
    wird also weder im code noch beim lokalisieren einfacher/schneller.

    edit: bei uns gehts um ca 10.000 key-value pairs (etwa 1000 davon haben parameter).

  • torquato schrieb:

    MyMattes schrieb:

    Edit: Wenn jetzt im Verwürfelungsfall noch im Code auf die Richtigkeit der Parameter-Reihenfolge geprüft werden soll, wird's tricky...
    Die Reihenfolge der Parameter hängt aber doch von der Zielsprache ab. Das kann man doch gar nicht durch einen Vergleich mit der Quellsprache auf Korrektheit überprüfen.

    Ein etwas an den Haaren herbeigezogenes Beispiel (mir fällt spontan nichts besseres ein):

    Deutsch: ein Drittel == 1/3
    Japanisch: ３分の１（さんぶんのいち = sanbun no ichi）
    aber man kann prüfen ob ein zahlnwert nicht an einer stelle verwendet wird für den ein string vorgesehen ist.

  • MyMattes schrieb:


    Andererseits muss m. E. eine App eh in jeder Zielsprache getestet werden, so dass fehlerhafte Lokalisierungsstrings dabei auffallen ... und ja keine Prüfung zur Laufzeit erfordern.
    Das ist die THEORIE. In Realität ist das leider nicht so denn jene die das Programm durchtesten und an 90% der Werte kommen (100% sind utopisch), sind meist keine native speakers und überfliegen den text auch oft nur... bei 10.000 kay-value pairs in den strings-files ist das auch einiges an arbeit (dazu kommen dann ja noch di massen an texten die direkt in den xib files verwendet werden - bei denen gibts dann aber eh keine probleme mit parameter, korrekturgelesen werden müssen sie aber auch...)