Translation Strings - Translations for apps via AI + human (if needed) | Product...
source link: https://www.producthunt.com/posts/translation-strings
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Support is great. Feedback is even better.
"We know we will not win any awards for the UX or for the design... but we think the concept is strong. What do you think? Is this something you would use? Are there features missing that would prevent you from using it?"
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
I am genuinely impressed by the launch of Translation Strings. The ingenuity and thoughtfulness of the features introduced in this product showcase the dedication and talent of the makers. I applaud your efforts in addressing the pain points of developers and translators, streamlining the process of creating multilingual applications.
The seamless integration, real-time collaboration, and version control capabilities are powerful and user-friendly. These features will undoubtedly save countless hours for teams working on global projects and significantly impact the audience.
I have one meaningful question for the makers: How do you envision the future of Translation Strings in terms of supporting niche languages and dialects to further empower localization efforts?
Once again, congratulations on this incredible product launch, and I am excited to see what's next for Translation Strings and its users.
@anastasiia_veselova, amazing reply! Thank you so much!
That's actually a fun idea; maybe we should build into this tool the ability to add the user's own comments to the GPT prompt, eg: "also translate this into London cockney rhyming slang". Or maybe even let the user add their own languages... eg "Klingon". That would be kind of fun to see the output!
But to be honest, with GPT 3.5, for languages that have less content online; we found the output to be OK and not good. One language that fits into this category is Romanian. We translated Translation Strings into Romanian with Translation Strings and then asked a native speaker what they thought of it... basically... "don't go live with output".
So, unfortunately, it seems with 3.5 the limitation is purely down to the lack of content for some languages inside of the engine.
We have not tried GPT4 yet but mainly because it is so much slower...
@dzianis_yatsenka great question! We also have apps in both...
With the app stores, we have found that the biggest pain point is sending out the app with the translations embedded as then a change requires a new app release... not optimum!
In Liffery, before we go public live we intend to change how the translations are pulled into the app. Today, webpack bundles the JSON into the app. We will instead change this.
We intend to configure the app to be bundled with a JSON file... but then on load also look for updates, when there are updates they will then be written to file within the app and i18n will load the translations from there instead... this will also allow is to play with AB testing.
2 features we will need in Translation Strings is... AB options but also... project-key + lang-code last updated.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK