Drop Locale

.properties translator that runs in your browser

Drop a .properties file in below, pick a target language, download the translated file. The .properties file stays on your device.

Loading translator...

How it works

Drop a .properties file on the page, click to choose one, or paste the contents straight in. The parser reads the file in your browser and tells you how many strings still need translation. Pick a target language and translation starts immediately. The translated file is reassembled from the same parsed structure so the original comments, key order, separator choice, and continuation-line layout all survive the round trip.

Quality Warning

Please don’t rely on the quality of these translations to ship a finalized product. This is just a starting point. It’s machine translation and there are no guarantees about its quality.

What we do not do

The file itself never leaves your device. We do not see what you are translating, we do not store any of the strings, and there is nothing about your file in our logs. The privacy wedge in DropFormat is structural: the .properties parser, the Google Translate caller, and the file writer all run inside your browser tab.

What does leave your device: the individual strings go to translate.googleapis.com the same way they would if you pasted them into translate.google.com yourself. We are not in the middle. If your file contains internal product strings you do not want a third party to see, do not translate it here; use an offline tool.

What it supports

.properties is the plain-text resource-bundle format Java has shipped since the 1990s and that Spring, Spring Boot, Struts, Android (legacy), Eclipse plugins, and many other JVM and IDE ecosystems still use today. Each line is a “key = value” pair (or “key : value”, or “key value”, since the spec allows all three separators). We preserve all of it on round trip: insertion order, comment lines (both # and ! styles), blank lines, indentation, and per-line separator choice.

Escape sequences are first class. The parser unescapes \n, \t, \r, \f, \\, \=, \:, \#, \!, and \uXXXX Unicode escapes before translation. The compiler re-escapes them on the way out, so the output file reloads byte-equivalent in any spec-compliant Properties reader (java.util.Properties.load, Spring’s PropertyResourceBundle, Android’s resource loader, IntelliJ’s localization plugin).

Continuation lines are joined on parse. A line ending in a single backslash continues onto the next physical line; the joined value is what gets translated. On download every entry is emitted on a single line. The file still loads identically because continuation is syntactic sugar.

Java .properties has no native plural concept (the JVM solution is ICU MessageFormat patterns inside the value string), so every entry here is a flat single-form key/value pair. Placeholders like {0} and {userName} pass through the translator unchanged.

Not yet: locale variants encoded in the file name (e.g. messages_fr_CA.properties) are not auto-renamed on download; the output keeps the original file name with a .translated.properties suffix. Rename it to match your locale convention before placing it in your resource bundle.

What we tolerate, and what we reject

Some malformed files we repair on the way in. Others we refuse to load so we do not make things worse. This list is the parser’s actual behaviour, generated from the format module itself, not aspirational copy.

Repaired automatically:

  • UTF-8 byte order mark (BOM) at the start of the file
  • Windows (CRLF) or mixed line endings
  • File truncated mid-line at the tail (we keep complete lines)

Refused with an explanation:

  • Empty file. Add at least one key=value line and re-upload.
  • No translatable entries (comments only). Add at least one key=value line.
  • Looks like a different translation format (PO, ARB, XLIFF, .xcstrings). Use the /translate/ hub to pick the right translator.

Common questions

Why is the translation in some cases worse than the Google Translate website? The free endpoint we use is the same one the Google Translate website uses, but the API does not always know about the context the website’s interface provides. For names, branded terms, or jargon, expect to override in the review pane.

What if I am translating something Google’s endpoint will not accept? The free endpoint occasionally returns the source unchanged for content it would rather not translate. Those entries show “kept original” in the review pane so you can hand-translate just those.

Does it cache anything? No. Each run starts fresh.

Will the output be a valid .properties file? Yes. The compiler re-escapes structurally meaningful characters and emits one entry per line. The file loads cleanly in java.util.Properties.load, Spring’s resource-bundle loader, and any IDE plugin that reads .properties.

What about MessageFormat / ICU patterns inside values? The translator treats them as opaque strings and passes them through unchanged. Placeholder protection (the same masking layer the PO and XLIFF translators use) keeps {0}, {userName}, and similar from being mangled by the machine translator.

What about ISO-8859-1 .properties files? The legacy Java spec required ISO-8859-1 encoding with \uXXXX escapes for non-ASCII characters. Modern Java accepts UTF-8 too. We assume UTF-8 on input; if you have a legacy ISO-8859-1 file, save it as UTF-8 first.

Why this exists

Most JVM localization tooling expects you to either pay for a managed translation service or run a CLI against your local files. This tool sits in between: free, browser-based, no upload, designed for the “I just need a fast first pass on this resource bundle” workflow. Drop the .properties, pick the language, get back a translated file in the same shape.

What is .properties?

.properties is the plain-text resource-bundle format defined by java.util.Properties in the Java standard library. Each file is a flat list of “key = value” pairs that the JVM loads at startup to localize an application’s UI strings, configuration defaults, or any other text the runtime needs to swap by locale. The format predates JSON, XML resource files, and most modern alternatives, so it shows up across Java, Spring, Spring Boot, Struts, JBoss, Eclipse plugins, IntelliJ plugins, legacy Android resource bundles, and a long tail of JVM-adjacent tools (Gradle, Maven, Ant). A typical resource bundle is a family of files like messages.properties, messages_fr.properties, messages_de.properties; the JVM picks the right file based on the user’s locale and falls back to the base file when a translation is missing.