AI-driven i18n - because managing translations is just a pain. - Almost any language, formal and informal. - Version history of each string. - Integrate into your apps via our API. - It's also free (v0.1 - it's ugly, I know)
Hey Product Hunt friends!
At Liffery, we're just getting ready for our public launch, and in doing so, we're getting the platform translated... but... having gone through the joys of i18n before, coordinating translators and developers is always challenging, and this time I wanted to see if we could optimise the process.
With this utility tool for app development teams, we wanted versioning, translation context and an API for DevOps.
But we also wanted to speed the whole thing up... a lot... so we mixed in ChatGPT.
After a few days of rapid development, the database model is stable, the API is stable, and the access to ChatGPT is rock solid, so we thought... why not just release this on a domain for all to access and see what people think.
We have a few ideas for where we would like to take this (starting with getting a UX and graphics designer on board to make it look less 1992), but we would love to hear your thoughts!
Happy translating :D
John
PS: There are not many glossy images for this mini project yet, but the video explains most features.
Cool project. But, the approach you are taking (of having an API to fetch translations from) will eventually fall apart.
Developers and translators will simultaneously change translations. Technically, you have no possibility of merging changes from developers and translators if you don't have version control with branching support on your database. I explained the technical challenges and solutions in this video https://youtu.be/CZr6A5gwmFs?t=825.
TL;DR we are building turning git into a database now and building localization infrastructure. If you want to reduce maintenance effort + have a better i18n experience, you could build translations strings on top of https://github.com/inlang/inlang. See https://inlang.com/documentation....
@samuel_stroschein actually the API does comparison checks as the new data is provided. Updating if needed, creating if new... or ignoring if it is exactly the same. So you can just keep throwing data at it all day long, the same, different... it will just all be handled by the API.
I think i mentioned it in the vid but, the translations are also versioned :)
There are a few other platforms that do this already but... we just wanted one with ChatGPT thrown into the mix :)
In other words.. it will not fall apart as you say.
@samuel_stroschein but that is a good point! I will get the video update thank you!
Ref.: managing bigger teams with translation strings. In my experience over the last 15-20 years, devs should not be writing the copy - only add placeholders for the copy-writers. My experience with the majority of no-techy folk is git is not a nice place for them to be.
The way we work with Translation Strings, is simple... the devs work in the JSON files as they always have. They work in 1 language (for us English). And so.. all changes for this are managed in git.. just as it always has been.
Depending on how your app is setup, you will either have 1 big JSON file, or lots of smaller JSON files that a for areas of the app.
The dev works up a feature, the feature is tested and merged into branch develop (aka gitflow). However, before we move to production the translations are checked by the copy writers (this could be finallised before the feature, and give the dev the text to copy and paste in) but for us it is more efficient this way... and now with Translation Strings, automatically translating... we have English to 6 other other languages in the no time!
I guess 1 big improvement there would be to have a simple sync tool between the IDE and the API of Translation Strings... but for now, with this POC, the workflow will always be to take the English file from the code, put into Translation Strings, and then pull back out int the app along with all the other translations.
Thanks for the idea 💡 great feedback
@john_carmichael Thanks for the detailed response!
Re managing larger teams: Absolutely, devs should work in git and translators should have an easy way to manage translations.
> I guess 1 big improvement there would be to have a simple sync tool between the IDE and the API of Translation Strings
This is the moment you will eventually need version control on your database layer. Syncing state with branches will become a nightmare/impossible (been there done that :D).
Congrats on the launch of your new product.🚀
You've put in a lot of hard work and we know it will pay off😊
👍 Just tried Liffery's translation utility tool and it's a game-changer! Versioning, translation context, and an API for DevOps all in one. Plus, ChatGPT integration makes it lightning-fast. Excited to see where they take it! 🚀
keep it up @john_carmichael and @janine_nitz
Liffery
Sealit
Liffery
Sealit
inlang IDE Extension (i18n)
Liffery
Liffery
inlang IDE Extension (i18n)