i18n translation request for comments

[frankli0324]

this is a long needed feature. game organizers often struggles on internalization, and it's boring and time wasting.

I've started some coding on https://github.com/frankli0324/CTFd/tree/feat/i18n-backend, want some comments. it's after writing all these (below) that I realized that ColdHeat already added the 3.6 milestone... I think I could help with that? I think I'll post it anyway...

---

let alone whether this implementation is good or bad, it's needed.

things I've considered:

although CTFd is designed as a flask app, it's splitted into frontend and backend. However CTFd still relies heavily on template rendering. That makes us to take three parts into consideration when adding i18n:

• javascript, which handles the rendering of some backend-irrelevant data.
• Jinja templates, I think we could inject an i18n function into the environment to use in the templates.
• python backend, which returns some of the messages, and that's what I'm working on right now.

for the first part, maybe CTFd could consider it a job for theme developers, but it would be nice if the core theme could provide some i18n abilities.

I've attempted to take the i18n entirely to the frontend in #1083, but it seems that it's a bad idea.

I believe that CTFd could easily achieve:

• letting the game admin set a default language for all users
• let the user override the language

with this work done.

[ColdHeat]

I took a quick skim through your branch and I like the general idea. I think I would rather a few ideas:

• Instead of storing translations in Python storing translations in a .po file. We will want to have translations be processable outside of CTFd in a regular translation app.
• Using _() instead of i() similar to regular gettext. In fact I think you should simply use gettext.

In general, we shouldn't need to consider the JS for translations anymore. There shouldn't be any language in CTFd.js or in the core-beta JS. If there is, we should probably try to remove it.

[frankli0324]

the reason I hesitated to use gettext is that I find that in some cases (not only about singular and plural, in which the case, cjk languages works in a completely different way) gettext is incapable of handling the differences between English and Chinese nicely, and with python functions I could handle them better. I'll try moving back to gettext once the translation itself's done.

[frankli0324]

after digging around a little, I find i18next format more promising than the gnu gettext. it's supported by translation collab platforms like Crowdin, and makes much more sense than gettext in terms of format design. (at least no .mo, .po compiling gibberish) well... it seems that no one writes a python library for it, yet https://github.com/danhper/python-i18n seems nice, but it also seems to be outdated and inventing it's own format... babel on the other hand, is built on top of gettext. it supports compiling .po to .mo, but sounds an overkill and complicates the integration flow