Add translations for helps.

[bckohan]

Should make a good faith effort to provide translations for all the languages Django provides translations for.

[bckohan]

One wrinkle here is that typer adds some of the help text for (i.e. --help) - that may eventually be wrapped in gettext and if it is - how do the native python translation and django translation systems work together?

[bckohan]

Does django have translations for the common options?

[bckohan]

We will not translate error messages presented on the terminal per Django's practice. I do think translating the default CLI helps is important because the CLI interface may be used by non-devs. Consider using google translate: https://github.com/ankitpopli1891/django-autotranslate

[oliverandrich]

What is the rationale behind including it? Will it be an optional dependency? And shouldn't it be up to the project, including django-typer to supply the translation? I would use django-translate either for all of my project or not at all. But it would surprise me, if one third-party library handles it on its own.

[bckohan]

It would only be a development dependency, it wouldn't register on pypi at all. Translations would be produced at package time.

Django's stance toward translation so far as I can tell is that if it's language that only developers are exposed to the strings are not translated and if it's language downstream users are exposed to it is translated. Django does not offer translations out of the box for the helps for default command parameters. Probably because this language is thought of as in the first category. I'm not sure I agree with this. I think the CLI interface of a Django site probably falls somewhere between the developer only audience and the user audience. As such I think it makes sense to provide translations out of the box for the common parameters.

[oliverandrich]

Thanks for the clarification. I am a bit torn whether to translate commands or not. Lately, I have switched to skipping this extra step and go with English text there. The reason is, that most of the system we are deploying to are either C.UTF-8 or en_US.UTF-8. Just a handful uses de_DE.UTF-8 and would profit from a translation. Maybe the stance of Django is reasonable and pragmatic.

[bckohan]

Yeah, I wrestled with it too. I'm leaning towards yes for a few reasons:

1. It's pretty easy to use a different settings module when using the CLI, so even if your production site was configured for a default language other than english and you still wanted the CLI to render in english, you could just switch the default language for management mode.
2. I have this notion that one could use the type hints in the CLI to automagically build an admin web UI for configuring and scheduling management commands (think crontab but through the admin) and if you did that it'd be nice to have the translations available.

[bckohan]

Also further clarification. I'm not talking about building translation infrastructure for commands that use django-typer, only including a .po file that contains google translate generated translations for the help strings of the common parameters. Params like --verbosity or --settings

[oliverandrich]

Ah. Now I am in sync with you. The last comment closed a gap in my mind and the mentioning of the dev dependency also makes sense. This makes total sense.

[bckohan]

@oliverandrich sanity check, does this make any sense?

original english:

[oliverandrich]

They look pretty good to me. I would have translated "settings modul" as "Modul für Einstellungen" instead of "Einstellungsmodul". But this is basically a stylistic question and not incorrect.

[bckohan]

The remaining task here is to figure out how to get stdlib gettext translations in upstream Typer to work with the django translation system 🤔

[bckohan]

Both click and typer wrap strings in stdlib gettext. These are mostly error strings and help markers (things like [OPTIONS]). The only way to really incorporate these is to monkey patch the gettext function calls upstream. This works but is icky/brittle. Because the use case here is generating translated UIs from the helps for an admin command runner or something like that - it's not critical that the markers/errors to be translated because they wouldn't appear in that UI anyway.

I'm considering the help translations to be good enough and kicking the rest of this can down the road. No reason it should hold up a 3.0 release.

There should probably be an official Django supported mechanism for dealing with dependency libraries that use stdlib gettext. Perhaps even monkey patching the stdlib gettext calls....