Translations using gettext instead of csv?

Problems or limitations

While I'm not particularly attached to this project (in fact, I learned about it lurking in godot's subreddit) or have anything against it, but I noticed that for translations you use csv files (which it seems that you store in yaml that later will be packed to several csv files...) instead of gettext system (that Godot introduced support for in Godot 4) which will probably suit much better, especially in future when there will be much more strings and more different languages.

Feature to solve the problem

Since gettext specifically was born for dealing with translations, there not much reasons to not using it.

It is standardized (much more then some csv file) especially when it come to features such as pluralization or documentation or anything related to translations. And beside features, standardization means that there already exist great tools to deal with gettext, for example, poeditor.

It's much easier to translate using gettext from translator viewpoint. You can easily create new locales from interface of software such as poedit with much easy, specify rules for pluralization (which is done mostly automatically for you by software, but you still provide your own), see outdated or changed or new string (once you will generate new pot file, translator can merge it with their po file so everything that outdated or changed will be automatically considered "fuzzy" so translator will see them without you, developer, being involved in this process), have support for translation memory (very useful feature that you won't get much editing some csv files using text editors) and just in general you have much better experience. And, also, translators can leave translation specific comments in their file (yet another great feature of gettext), so next translator can see why previous translator might used that wording or translated something in that way, etc.

From your pov of developer with Godot it's also very easy. You just add resources that need to be translated to pot generation in project settings (resources such as scripts, scenes, etc) and then click "Generate POT" once in while when you want your translators to update their translations. (And, translations itself for your game stored in source, that gettext collects from there and compile pot file from it that translators will use later.) You can even provide context to your translations (2nd argument in tr and 3rd in tr_n functions) that will be used to distinguish same strings for different context, and also will be used to neatly sort list of string in po file, so translator will have much better time translating your stuff. Also, gettext has support for special comments system that will be addressed directly to translators (TRANSLATORS:), but as of now, godot doesn't implemented it sadly. I opened proposal for it https://github.com/godotengine/godot-proposals/issues/8555, so it might be added in near/far future.

Other informations

TLDR: use gettext for translation support of your program, not csv. Since you only starting, it might be much easier to move to gettext. Here godot docs about: https://docs.godotengine.org/en/stable/tutorials/i18n/localization_using_gettext.html (if you have questions about gettext, I might answer them, since I kinda already familiar with it in terms of user|translator and as developer.)

I'm talking about all of this because I kinda translator myself. In my profile you can found several fork of repos (mostly GTK software) that I translated (Mostly in Ukrainian language, but sometimes also Russian alongside) that also uses gettext. And let me tell you: gettext is just much-much-much better then some csv/json/whatever-system-and-format, especially when you translate and maintain translations for several projects. gettext + Poeditor just makes translator's life so easy, which in return will provide you with better translations.

TLDR2: Please, consider moving to gettext instead of this yaml to csv stuff.

I have been experimenting with the pot file system today. It is great that I can generate them very easily by just selecting the scene. But it gets quite confusing from that point onwards. There won't be too many translations needed for this project so I'll stick with my YAML to csv approach for now whilst I learn more about gettext which will probably take some time. I don't want to switch the systems I use from one day to another.

At this moment we use YAML to get over the limitations when using csv with git. This approach may change in the future, to gettext or to a solution which would be easier for people to contribute to. However, YAML is quite easy and user friendly which makes it also very useful for people to contribute, this will change however as soon as we start having many more and more languages and keys.

So far there is also nobody in the team of contributors with gettext knowledge, which makes transitioning to that system a lot more troublesome/difficult. Updating pot files in Crowdin also removes the previously made adjustments to the context part (this is probably by design?). Right now I use clear keys which define what's a title, a popup, ... and that is within the key name. For pop files it takes the original string in English, which I think makes it more complicated for translators to know what a correct translation could be.

But I see your point, the moment that this project would grow, using something standardized such at gettext could be beneficial so I will think about it and test it out every now and then. I have a busy schedule so testing this could take time. Thank you for bringing this to my attention and taking your time to write this.

VoylinsGamedevJourney / gozen