Show HN: I coded my own JSON translation tool to easily localize my side project (opens in new tab)

>Perfect for manage project localization

>This credits will never expire.

>So if you sync new o modified content

There are obvious mistakes in the English version of your website, which is totally bizarre to me, since these errors are absent in the German version. My guess is that the AI actually fixed these errors when translating.

I have to say that the German translation is really bad though.

"Habe nach einem Online-JSON-Editor gesucht, aber nur Enterprise-Tools gefunden, die nicht das bieten, was ich brauchte, also...

Ich habe mein eigenes JSON-Übersetzungstool erstellt. "

Dropping the "Ich" at the beginning of the first sentence makes it sound like total slang. And the transition between the paragraphs does not work in German (due to the verb being at a different position compared to English). It sounds extremely clunky.

"Prost!"

This just is not an appropriate translation.

"Hier ist was sie über Quicklang."

This isn't a complete sentence. It misses an essential component.

"Holen Quicklang"

Nonsensical translation.

"lokalisieren Sie Ihre SaaS-, App-, KI-Produkt- oder Website, um Ihnen das weltweite Versenden zu erleichtern."

I don't get what that means. The AI translated shipping as sending. It should have been "um Ihnen den weltweiten Vertrieb zu erleichtern", or something like that.

I usually hate nitpicking on stuff like this and I wouldn't have mentioned it if the product was anything else. But surely you can present your product in a better way.

I've built a fairly sophisticated web-based translation tool for an agency's client who demanded it.

I built it to their spec, for their CMS. They didn't use it, because the scheme they wanted turned out to be too much bother, and they couldn't find translation agencies who would bother with it.

The reality is that if you want to make it easy to keep translations up-to-date, you actually have to support all the (confusing, frustrating) translation infrastructure built around .PO files. Because then you have the support of translation agencies, tooling, even Crowdin etc.

Trying to short-circuit this with clever minimal bespoke JSON and ChatGPT is probably a mistake: this is a job where you will ultimately want actual people with actual multilingual ability working for you, and if you don't use the normal tooling you'll find it difficult to attract contributors even with open source.

Interesting! How about using Deepl as a translation backend? I got some good results for translation strings with {{placeholders}} that needed to be ignored in the translations. Its api also has some neat features like formality, glossaries and context(experimental).

Ps. I'm working on a similar opensource tool to speed up the i18n process ( https://codeberg.org/garage44/expressio)

There's a much easier way to translate json

    cat english.json | sed 's/"\([^"]*\)"/«\1»/g' > french.json

plugging my own project:

https://github.com/KevinColemanInc/i18n-translate-go

Works well for i18njs. The issues I ran into are: chat-gpt didn't translate all the keys in the batch (especially for obscure languages like Laos) and sometimes the chatgpt output invalid unicode (see error in the readme).

have you thought about automatically generating json language files from pure html? Say I have an app that does not yet use a language file but just code like

<strong>Hello World</strong>

And on-the-fly translation? Say I have a backend that returns english language but I need it to translate it to another language on the fly? It could check whether the translation is available and otherwise generate it and store it. The original text key could be a hash of the text and you probably need in-memory key lookup for those hashes.

Honestly, I don't see the reason to pay $10/month just to translate a json file.Or is this just another OpenAI API caller startup? "In any case, we must use LLM?"

disclaimer: i'm the founder of https://inlang.com/

monetizing your solution will likely be a dead end.

the value prop of your solution doesn't match the app you built, and what buyers pay for. for example, machine translating translation files is easier for you to build and developers to use with a cli [0] instead of a web app. there is no value in rendering json in the web app. vscode does a better job at rendering json's.

you could monetize via a web app if you allow non-devs to edit translations. but that's a beast called CAT editor [1], where you need to support all sorts of different file formats. aka, the value of a CAT editor is the file support and ecosystem around it, not the editor itself.

[0] https://inlang.com/m/2qj2w8pu/app-inlang-cli#machine-transla...

[1] https://inlang.com/m/tdozzpar/app-inlang-finkLocalizationEdi...

I'd use this to do a quick and dirty localization, but quality localization is hard and expensive even for skilled humans. For example, see Super Mario RPG for SNES's localization which had a bunch of idioms and references to other games and anime go over the localizers' heads and become non-sensical phrases in English ("キイーッウキイーーッ！ あの時の赤んぼう！？", a reference to Yoshi's Island became "That's...my child?" which makes no sense)

Ever heard of .po files?

Very cool, I've done similar in the past. One point of contention is that I like YAML more than JSON for this kind of effort as multi-line text is much easier to deal with. I'd also generate typescript definitions based on the YAML/JSON for the default built values that has tended to help with the dev side (at least for JS/web projects).

Looks really cool, minor typo on the landing page:

Strunggle with i18n -> Struggle with i18n ^

That could be great for a customer of mine. They have the documentation of their API on Postman and they want to translate it into other languages. Postman don't seem to have support for multiple languages so we would have to either manually manage multiple versions of the documentation (but managing the examples could be a nightmare) or export as JSON, identify and update the changes, import. This service could automate the middle part of that process.

Ok, so I have my translation, and I am not quite sure what to do now... Do I just copy-paste into my `messages.json`?

Hey HN.

I got tired of manually copy/pasting translations from ChatGPT every time I updated my main language JSON file. So I build my own alternative.

Joan

If this for your side project and your just using machine translation anyways - if this saves you steps, go for it. When it comes down to an actual product, as a consumer, most would rather buy a product that's been proofread by someone for the language/region they use it in, quality can only improve. I'm not against bootstrapping translations with AI, but they are more than strings that serve functions, they are human language that evoke emotion and associations - proofreading is important to me in something I might have to pay for. And human language is super important sometimes, and most of us can really only think/feel in a singular one. If my language comes across wrong here, it will undermine my point.

I don't mean to be critical, sounds like something I could actually use occasionally. I sometimes feel like I'm the only one putting up this common sense fight: if designers can spend hours crafting something carefully worded, tailored in English for something, why would it make sense to just take that and auto-translate it into something that if it's wrong gets discovered in the market as some very awkward in-app experience where the words don't make sense so much someone complains? My only gripe is people thinking AI is the total substitute for localization, it's not a silver bullet, but sure is better than nothing.

Disclaimer: I'm the tech co-founder at https://replexica.com.

I like the idea.

At Replexica we've basically built a better + much faster (+ sometimes cheaper) alternative to Lokalise, Phrase, and Crowdin (we help dev teams do AI translations of user interfaces - web, mobile, Apple Vision Pro, etc.). So having seen some things, I must say AI-powered localization is indeed the future, but it's very, very hard to get it right.

For example, it took us a while to perfect the quality. Working with the "industry standard" scores (BLEU, etc.) isn't easy, and the state of the machine translation industry feels very last century, so you have to oftentimes invent things by studying the latest research.

It's a constant quest to ensure the user gets the best, perfect result, and not to mention, different LLMs perform differently with different language pairs, which adds an extra challenge to maintaining accuracy while iterating. For example, we had to build a regression testing setup internally, to make sure the quality only improves as we ship.

Nevertheless, good luck. I will be keeping an eye on your progress.

BTW, loving your domain name.

EDIT: typos