@maria_brm Thank you! hope it will help over at Sealit!

@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).

@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.

@ivica_popovic thanks 😊

@pjw yuuppp... it is not 100% accurate unless you put in the content for the harder-to-understand translation strings, but I translated all of "Translation Strings" with "Translation Strings" in a coffee break! A couple of errors but... it's definitely a game changer for us at Liffery!

@korkmaz :D ok.. well maybe we will stick with the old school design :) maybe throw in a couple of frames in there too... if only browsers still supported Adobe Flash!

@rasmus_sorensen wooop! Please do.. this is mainly an internal tool for us at Liffery right now, but if we get enough interest, we'll look into building this up as a much more polished product.

Thank you @ozan_yalcin1 ... but the question is... would you use it for your apps?

@maxtpham to be honest... when I put this one together over the easter weekend, it was really just for my own use in Liffery. Maybe I will have to think about a free and paid access in the future if it gets any traction... probably something like an API consumption model. Free for the small apps, paid for the bigger ones... but would you pay for a tool like this?

@richard_gao2 😁 you're welcome

@matthias_strafinger thanks 😊 it will be interesting to see the general interest in this one... to continue general feature development on it ot not...

@onejamel cheers! If this was a polished product, smooth UX and design with integration into IDEs... is this something you pay for?