Thank you! Just tested with Turkish and yes the quality doesn't seem to be the best, however in the future I plan to add translation models with higher quality, so I hope that those will do better with this language.
Just for the reference, what I have to face with:
"Sizinde Sular kokuyormu çok kötü koku var baneda mutfakta"
NLLB gives: "You smell like water. It smells bad in the kitchen."
The right translation is "Do your waters also smell? There is a very bad odor in my kitchen too."
"Bu bina elektronik bir sistem var dış kapı -otomatik- uydu -asansör elektrik yoksa hiç biri çalışmaz yanlış sigorta kapatılıp açılırsa böyle sıkıntı olur"
NLLB: "This building has an electronic system. An external door. An automatic satellite. An electric elevator. If none of them are working, it's a problem."
Should look like "This building has an electronic system with an automatic exterior door, satellite, and elevator. If there is no electricity, none of them work. If the wrong fuse is turned off and on, such problems occur."
They have regular punctuation marks like dots, commas, questions, and exclamations, but, for some reason, they don't use these in chats. I don't know why, but it hardens translations a lot.
I bookmarked/starred the repo to track the updates :) Just to clarify - no pressure, obligations, expectations, etc. Just my feedback with couple of samples, hope that helps.
The position sent to Google is an error that I didn't see (I will correct it in 5 minutes), the rest, as I say in the readme, is due to the fact that the privacy policy used for RTranslator 2.0 for now is the same as RTranslator 1.0 (that used Google's Api), I will make a new privacy policy contract for RTranslator 2.0 with a lawyer soon.
With a Snapdragon 8 Plus Gen 1, I measured about 2 seconds for speech recognition of 30s of audio (although for shorter durations it takes not much less than 2s), while for translation about 2 seconds for a text of 300 characters (in this case, however, the performance scales linearly based on the length of the text).
Thank you for the feedback! In a little while I plan to redo the entire graphic interface, and yes a method to make it clearer when the microphone is listening is already in the plans. As for the cutting of sentences you can probably solve it by increasing the microphone's sensitivity from the app settings (from there you can also change other settings regarding the activation of the microphone, but most likely it is a sensitivity problem).
That would be the end goal (very far :D). But yeah, joking aside, I aim to make the translation better and better as technology advances, the current level is a usable start but maybe one day it will be truly seamless.
Thank you! The app can be used on any device that has more than 6GB of RAM, with a phone with the right amount of RAM but a slower CPU the only effect is that the app takes longer to perform the translation and voice recognition (at least from my tests it shouldn't lag, so it's always usable), but yes, maybe in the future when I have the opportunity to test it with enough devices I will make a list with the performances for various Socs.
Thank you! I've done the launch on ProductHunt years ago, when the app still used Google APIs and required the developer key, I'll make another one soon. Regarding the release of the iOS version for now it's not in my plans, but if the app is successful and I make enough money with donations in the future I might consider it (since I would have to buy a Mac and at least 2 iPhones to test the Conversation mode), and always if the App store's policies will not be too restrictive.
As an iOS developer, that could definitely use this, I completely support you, in keeping it Android native.
I’m a believer in native software (I write native software). I think it results in much higher Quality user experience, than hybrid development.
There’s a reason that it’s not super-popular, though. It’s a fair bit more expensive than hybrid approaches, and generally requires a higher skill level, as well. Most companies find that hybrid approaches are “good enough,” and they make much better margins.
That said, you could probably test it, using the Xcode Simulator. It’s gotten pretty good with I/O, lately. Bluetooth still requires a physical device, but most of the stuff could probably be tested fine, if you used a modular approach (my preferred methodology).
Yes I agree with you, moreover for now I am much better as a Java or C developer than as a web developer, so for me the native approach is also simpler. However, yes, I practically never use the emulator even for Android precisely because I have to test Bluetooth, which at least in my experience on Android, is the most difficult part.
Thank you, for now it's not in my plans, but if the app is successful and I make enough money with donations in the future I might consider it (since I would have to buy a Mac and at least 2 iPhones to test the Conversation mode), and always if the App store's policies will not be too restrictive.
