Hello everyone! Over the past day, I came up with an idea that I thought could benefit the entire platform.
I’ve created an open source service that allows you to fully translate your players chats, in real-time. While for the most part, game servers are one language, in some regions that is not the case, and there are occasional times when a Spanish user for example joins an English lobby.
I think this can make ROBLOX a lot more inclusive for the games that would use it, and would really suggest that ROBLOX look into making it a real feature in some ways.
Anyways, the code is available at OpenSky-Game and OpenSky-Server. You’re able to use the supplied API, but please make your own if you’re a high-volume user. Also note that the public API is incredibly unstable as it is hosted on 512MB of ram. If it starts getting spammed, it may just go offline.
It works essentially by intercepting chats and translating them if they are from differing languages.
I implore anybody to make pull requests to the repositories to make them better, after all I haven’t scripted on here in over a year.
I was under the impression that Roblox filtered languages equally. The difficulty is it might screw with the translation if I convert to English, filter, then convert to the desired language. Thanks for pointing it out, though
Once again thanks for the heads up. I have posted Major release v1.1.0 that implements filtering to the translated text. This complies with ROBLOX’s chat filtering system but I’m unable to control if their filter is weak in certain languages than others.
This is a good resource I just would like to correct you on your usage of semantic versioning.
v1.1.1 is not a minor release, it is a patch v1.1.0 should never be “full release”, that should typically be v1.0.0 (AKA. first major release)
When a project is not ready to be labeled “full release” it should be labelled respectively. i.e. v0.2.0-beta
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Other than that nitpick, this is a good resource. Good job. Hopefully your method of translation will not rate-limit your private token.
Edit: I’ve noticed you’re using Libretranslate, it’s a good pick so the individual using this has to buy their own license, as other services like Yandex and Google Translate would require $x/y calls, I’ve seen self-hosted translation projects that always ended up getting rate limited because they let their token be public-use.
Thanks. I’ve always thought that I’m able to version it whatever I want but I had no idea there’s a whole standard to it that prevents confusion. It’s my first time making anything open source so I don’t have the experience to know how to correctly version things.
I don’t use replit often but I just tested it with the project.
In any instance, you run pip install -r requirements.txt to install the dependencies (like the translator)
Then, just set your run command to gunicorn app:app (or execute that command every time you want to run)
Using those commands I found success hosting a replit. However, I like using render more as they seem much faster and reliable. It is totally personal preference, however.
