Kostenloses Werkzeug

.properties in JSON umwandeln

Resource Bundles aus Java, Spring und Kotlin auf der einen Seite, i18n-JSON auf der anderen, samt der Maskierungsregeln, an denen ein naives Zerteilen scheitert.

Läuft im Browser. Kein Konto, kein Upload, nichts verlässt den Rechner.

.propertiesJSON

Läuft im Browser. Die Datei wird nicht hochgeladen.

Drei Regeln, die split('=') falsch machen

Das properties-Format sieht aus wie Schlüssel gleich Wert und ist es nicht. Der Trenner darf ein Gleichheitszeichen sein, ein Doppelpunkt oder schlicht Leerraum: server.port 8080 ist ein gültiger Eintrag. Eine Zeile, die auf einen einzelnen Rückstrich endet, läuft in der nächsten weiter, wobei der führende Leerraum der Folgezeile wegfällt. Und der Schlüssel selbst darf einen maskierten Trenner enthalten: a\:b=c hat den Schlüssel a:b. Alle drei Fälle stehen in echten Spring-Bundles, und alle drei werden hier richtig gelesen. Alte Dateien mit \uXXXX für Nicht-ASCII werden beim Lesen aufgelöst.

Was heil bleibt

Umwandeln ist einfach. Die Datei nicht zu zerlegen ist die Arbeit.

Jeder Konverter, der eine Sprachdatei als Fließtext behandelt, liefert irgendwann einen Absturz aus. An diesen drei Stellen passiert es.

Platzhalter bleiben Platzhalter
%@, %lld, %1$s, {name} und {{count}} kommen genau so heraus, wie sie hineingegangen sind. Ein Platzhalter, der maskiert, umnummeriert oder übersetzt wurde, ist kein Schönheitsfehler, sondern ein Absturz auf dem Gerät.
Pluralformen bleiben getrennt
Xcodes variations, das plurals-Element von Android und msgstr[n] aus Gettext meinen dasselbe und schreiben es alle anders. Hier werden sie aufeinander abgebildet, statt zu einer Zeichenkette zusammenzufallen. Polnisch hat vier Formen; alle vier überleben.
Schlüssel behalten ihre Form
Verschachtelung, Punktpfade, Felder und Übersetzerhinweise gehen mit, wo das Zielformat einen Platz dafür hat. Wo nicht, steht es im Abschnitt darunter.

Was nicht mitkommt

Steht hier, weil man es sonst erst im kaputten Build erfährt.

Auf der Ebene der Texte nichts, aber geschrieben wird UTF-8 ohne \uXXXX-Maskierung, seit Java 9 die Voreinstellung für ResourceBundle. Wer noch eine ältere Laufzeit bedient, die properties als ISO-8859-1 liest, schickt das Ergebnis durch native2ascii. Kommentarzeilen unmittelbar über einem Eintrag werden dessen Übersetzerhinweis; frei stehende Kommentare gehen nicht mit.

So läuft es

  1. Schritt 1

    Datei hineingeben

    .properties auf das linke Feld ziehen, über den Knopf auswählen oder den Text einfügen. Nichts wird hochgeladen. Die Umwandlung läuft in diesem Tab.

  2. Schritt 2

    Ergebnis lesen

    Das JSON steht da, während getippt wird. Der Zähler unter dem Feld sagt, wie viele Schlüssel durchgekommen sind. Eine Datei, die die Hälfte verloren hat, sieht man sofort.

  3. Schritt 3

    Kopieren oder herunterladen

    Text in die Zwischenablage, oder als Datei mit der richtigen Endung. Der Pfeil in der Mitte dreht die Richtung um.

Eine Sprachdatei rein. 64 Sprachen raus.

Ein Format umzuwandeln ist der Teil, den man von Hand machen kann. 3.627 Schlüssel in 64 Sprachen zu übersetzen, ohne einen einzigen Platzhalter zu zerlegen, ist der Teil, den man nicht von Hand macht. Beim nächsten Release zahlt man nur für die Strings, die sich geändert haben.

19 € im Monat inkl. MwSt., monatlich kündbar.

Fragen

In meinen Werten stehen Gleichheitszeichen. Geht das?
Ja. Der Leser trennt am ersten unmaskierten Trenner: aus formel=a = b wird der Schlüssel formel mit dem Wert a = b. Das ist der häufigste Fehler selbstgebauter properties-Leser.
Werden mehrzeilige Werte unterstützt?
Ja. Eine Zeile, die auf eine ungerade Zahl Rückstriche endet, läuft weiter. Eine gerade Zahl heißt, dass der Wert tatsächlich auf einen Rückstrich endet und der Eintrag dort aufhört. Dieser Unterschied ist wichtig und wird beachtet.
Und \uXXXX in einem alten Bundle?
Wird beim Lesen aufgelöst, aus \u00f6 kommt ö an. Geschrieben wird als reines UTF-8, wie es modernes Java erwartet.
Kann ich JSON zurück in ein Bundle wandeln?
Ja, über den Pfeil. Trenner und Leerraum in Schlüsseln werden beim Schreiben maskiert, damit das Ergebnis sich unverändert zurücklesen lässt.