Preparing localization for all UI messages and russian localization

[belonesox]

• Preparing localization for all UI messages («trans», «blocktrans»)
• Add russian localization for all these messages

[marksweb]

Impressive @belonesox! Thank you for the contribution, will check this out properly soon.

[marksweb]

@belonesox Could you delete the .mo files and add .mo to the git ignore please?

They're generated files & typically a generated file isn't committed to git.

[belonesox]

OK, done, but there are different rules for these, and I follow that
https://github.com/groveco/django-sql-explorer/blob/master/explorer/locale/zh_Hans/LC_MESSAGES/django.mo
included in your git, your setup.py missed compilemessages flow, and now for all who would install django-sql-explorer from pip russian localization will not work out the box.

[marksweb]

@belonesox in my experience, packages don't need to ship with mo files because the Django project using the app will define its supported languages and the person deploying the app runs compile messages which then creates the mo files.

One of the main packages I use in this circumstance being Django allauth.

I can certainly build the command into the release pipeline. That way they'd go into the pip package.

[belonesox]

packages don't need to ship with mo files

• Every python/django package should contain in WHL file compiled «mo-files». Usually, these files stored on git
  https://github.com/django/django/tree/main/django/contrib/admin/locale/af/LC_MESSAGES

Theoretically, it possible to not store it (I cannot remember a project with such paradigm, just checked almost all my django deps wheels — and cannot find such project), but then setup.py should:

• have big deps in setup_requires (big django staff) and provide build flow in setup.py for building these mo-files.
• of course publish whl-builds in pypi with compiled mo-files.

because the Django project using the app will define its supported languages, and the person deploying the app runs compile messages which then creates the mo files.

• compilation «po → mo» (django_admin compilemessages) compiles '''all''' available language po-files, it does not depend of locales supported/selected by application.
• If user run django_admin compilemessages, it compiles locale only for user application, not for django applications that use this app.

[marksweb]

@belonesox Ah ok, if django stores it's mo files in git, then lets keep things consistent & do the same, if you don't mind?

Thanks for providing that extra info!

[belonesox]

OK, return "mo" back.

[belonesox]

Is something else need to merge this?

[marksweb]

@belonesox I added some comments about the way you've added the translation tags. Feel free to share any thoughts or I could merge & then make changes myself.

[belonesox]

I added some comments about the way you've added the translation tags

Sorry, I dont see them. There I should read these comments?

[marksweb]

@belonesox Hopefully you can see comments here.

[marksweb]

@belonesox I've released this is 2.3