Open rbrito opened 9 years ago
This sounds nice. Should we use i18n tools to extract the words and sentences to po files in order to use it? Meanwhile, just for a big picture of the project, as I understand, we are going to get rid of the interactive mode, right? So, what we are translating?
@shk3 we are suggested to localize (not just translate) messages, along with possible time, date and other data types people get used to read in own language/format/etc.
@shk3, the messages hat the program shows via the logging
module could (should?) be translated for the users.
This includes, among other things, the help messages etc. Many years ago I played with internationalizing a toy python script and it worked fine with the little knowledge that I had. But now that we are using more strings that are generated for us (via, e.g., argparse
), I don't know how to do that.
Furthermore, for translation, we would need help from native users, of course, which is why I just marked this issue with a new tag that I created ("help-needed").
@silpol @rbrito Sorry for the late response. My inbox has been overflowed by the notifications. In terms of localization, I am not sure how much users of edx really need localization, as edx currently only serves in English. Would users really need a non-English CLI tool?
@rbrito I don't have experience with i18n for Python CLI either. I've done some i18n over Django. How much i18n would CLIs have? My OSes are running in English, so I am actually not sure if they translate the help messages as well. Could anyone paste some output samples of translated CLIs?
Finally, are we going to keep this tool as a CLI? If it is a CLI, I assume most CLI users should know some basic English at least in my home country. Correct me if I am wrong.
I tend to agree that i18n for CLI tool feels questinable to me. First, it's additional work for developers, but also keep in mind that when something breaks, users may send issue report in their local language, which might be an unnecessay complication for us to investigate the issue.
@balta2ar I feel like we don't need worry too much about user reports as currently our GitHub pages are in English, which should discourage users from sending context in their native languages.
@rbrito Is there a reason why we need i18n? Is it because we want to allow more users to use our tool? In that case, maybe a GUI would be more helpful, and i18n on GUI should be easier.
@shk3, there are many CLI programs that are translated (e.g., those from the GNU project).
But I guess that we should invest better our resources and move on to provide a GUI, even if it is very simple. I originally proposed something like this on coursera-dl about two years ago: https://github.com/coursera-dl/coursera-dl/issues/184
You guys convinced me and I'm changing this bug report to be to build a GUI. We may draw inspiration from some of that bug report. It may be a sizable amount of work, but the users would love such a thing.
BTW, thanks for forming such a wonderful small community. You guys rock and it is fun to interact with intelligent programmers that share the same goals as mine. :)
/cc: @iemejia and @mxamin (from coursera-dl) included, of course!
Here is a service that seems to offer a platform for users to help with translation of programs:
https://crowdin.com/
Is there any interest in this? In particular, this would allow users to see messages translated to their native languages, instead of forcing them to use English.