ຄຳແນະນຳການຕັ້ງຄ່າ¶

ການຕິດຕັ້ງ Weblate¶

ຂຶ້ນຢູ່ກັບການຕັ້ງຄ່າ ແລະ ປະສົບການຂອງເຈົ້າ, ຈົ່ງເລືອກວິທີການຕິດຕັ້ງທີ່ເໝາະສົມສຳລັບເຈົ້າ:

ການຕິດຕັ້ງໂດຍໃຊ້ Docker, ແນະນຳສຳລັບການຕັ້ງຄ່າໃນການຜະລິດ (production).
ການຕິດຕັ້ງ Virtualenv, ແນະນຳສຳລັບການຕັ້ງຄ່າໃນການຜະລິດ:
ການຕິດຕັ້ງຈາກແຫຼ່ງລະຫັດ (Source), ແນະນຳສຳລັບການພັດທະນາ.
ການຕິດຕັ້ງເທິງ OpenShift
ການຕິດຕັ້ງເທິງ Kubernetes

ພາບລວມຂອງສະຖາປັດຕະຍະກຳ¶

ເວັບເຊີເວີ

ຈັດການການຮ້ອງຂໍ HTTP ຂາເຂົ້າ, ການໃຫ້ບໍລິການໄຟລ໌ Static.

Celery workers

ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery ຖືກປະຕິບັດທີ່ນີ້.

ຂຶ້ນຢູ່ກັບປະລິມານວຽກງານຂອງເຈົ້າ, ເຈົ້າອາດຕ້ອງການປັບແຕ່ງຈຳນວນ workers.

ໃຊ້ໂນດ (node) ສະເພາະເມື່ອຂະຫຍາຍ Weblate ທາງນອນ.

ເຊີເວີແອັບພລິເຄຊັນ

ເຊີເວີ WSGI ຫຼື ASGI ທີ່ໃຫ້ບໍລິການເວັບໄຊແກ່ຜູ້ໃຊ້.

ໃຊ້ໂນດ (node) ສະເພາະເມື່ອຂະຫຍາຍ Weblate ທາງນອນ.

ຖານຂໍ້ມູນ

ເຊີບເວີຖານຂໍ້ມູນ PostgreSQL ສຳລັບເກັບເນື້ອຫາທັງໝົດ, ເບິ່ງ ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate.

ໃຊ້ໂນດຖານຂໍ້ມູນສະເພາະສຳລັບເວັບໄຊທີ່ມີຄຳສັບທີ່ຖືກໂຮສຫຼາຍຮ້ອຍລ້ານຄຳ.

Datastore

Key/value datastore ເຊັ່ນ Valkey ຫຼື Redis server ສຳລັບແຄຊ (cache) ແລະ ຄິວວຽກງານ, ເບິ່ງ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery.

ໃຊ້ໂນດ (node) ສະເພາະເມື່ອຂະຫຍາຍ Weblate ທາງນອນ.

ລະບົບໄຟລ໌

ບ່ອນເກັບຂໍ້ມູນລະບົບໄຟລ໌ສຳລັບເກັບຮີໂປຊິທໍຣີ VCS ແລະ ຂໍ້ມູນຜູ້ໃຊ້ທີ່ອັບໂຫຼດ. ສິ່ງນີ້ຖືກແບ່ງປັນໂດຍທຸກຂະບວນການ.

ໃຊ້ບ່ອນເກັບຂໍ້ມູນແບບເນັດເວີກເມື່ອຂະຫຍາຍ Weblate ທາງນອນ.

ອີເມວເຊີບເວີ

ເຊີບເວີ SMTP ສຳລັບອີເມວຂາອອກ, ເບິ່ງ ການຕັ້ງຄ່າອີເມວຂາອອກ. ມັນສາມາດຖືກຈັດຫາໂດຍພາຍນອກ.

Hint

ການຕິດຕັ້ງໂດຍໃຊ້ Docker ລວມມີ PostgreSQL ແລະ Valkey, ເຮັດໃຫ້ການຕິດຕັ້ງງ່າຍຂຶ້ນ.

ຄວາມຕ້ອງການດ້ານຊອບແວ¶

ລະບົບປະຕິບັດການ¶

Weblate ເປັນທີ່ຮູ້ຈັກວ່າເຮັດວຽກໄດ້ໃນ Linux, FreeBSD ແລະ macOS. ລະບົບອື່ນທີ່ຄ້າຍຄື Unix ສ່ວນຫຼາຍກໍຈະເຮັດວຽກໄດ້ເຊັ່ນກັນ.

Weblate ບໍ່ໄດ້ຮັບການຮອງຮັບໃນ Windows. ແຕ່ມັນອາດຈະຍັງເຮັດວຽກໄດ້ ແລະ ແພັດຊ໌ (patches) ຕ່າງໆກໍຍິນດີຕ້ອນຮັບ.

See also

ພາບລວມຂອງສະຖາປັດຕະຍະກຳ ອະທິບາຍສະຖາປັດຕະຍະກຳ Weblate ໂດຍລວມ ແລະ ການບໍລິການທີ່ຈຳເປັນ.

Python dependencies¶

Weblate ຖືກຂຽນດ້ວຍ Python ແລະ ຮອງຮັບ Python 3.12 ຫຼື ໃໝ່ກວ່າ. ເຈົ້າສາມາດຕິດຕັ້ງ dependencies ໂດຍໃຊ້ pip ຫຼື ຈາກແພັກເກັດການແຈກຢາຍຂອງເຈົ້າ, ລາຍການເຕັມມີຢູ່ໃນ requirements.txt.

Dependencies ທີ່ສຳຄັນທີ່ສຸດ:

Django: https://www.djangoproject.com/
Celery: https://docs.celeryq.dev/
Translate Toolkit: https://toolkit.translatehouse.org/
translation-finder: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Django REST Framework: https://www.django-rest-framework.org/

Dependencies ເສີມ¶
ຕົວລະບຸ dependency ເສີມ	ແພັກເກັດ Python	ຄຸນສົມບັດ Weblate
`amazon`	boto3 django-ses	Amazon Translate, AWS SES e-mail backend
`asgi`	granian	ເຊີເວີ ASGI ສຳລັບ Weblate
`gelf`	logging-gelf	ການຈັດການ Log ແບບ Graylog
`gerrit`	git-review	ຄຳຮ້ອງຂໍການກວດສອບ Gerrit
`google`	google-cloud-storage google-cloud-translate	Google Cloud Translation Advanced ພ້ອມຮອງຮັບອະພິທານສັບ
`google-errors`	google-cloud-error-reporting	ການເກັບລາຍງານຂໍ້ຜິດພາດ ແລະ ການຕິດຕາມປະສິດທິພາບ
`ldap`	django-auth-ldap	ການຢືນຢັນຕົວຕົນ LDAP
`mercurial`	mercurial	Mercurial
`postgres`	psycopg	PostgreSQL, ເບິ່ງ ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate
`rollbar`	rollbar	ການເກັບລາຍງານຂໍ້ຜິດພາດ ແລະ ການຕິດຕາມປະສິດທິພາບ
`saml`	python3-saml xmlsec	ການຢືນຢັນຕົວຕົນ SAML
`saml2idp`	djangosaml2idp2	ການລວມ SAML 2 IDP ເຂົ້າໃນ Weblate
`sphinx`	Sphinx	ຈຳເປັນສຳລັບ ອັບເດດໄຟລ໌ POT (Sphinx)
`wllegal`	wllegal	ການລວມ Hosted Weblate
`wsgi`	granian	ເຊີເວີ WSGI ສຳລັບ Weblate
`zxcvbn`	django-zxcvbn-password-validator	ການຢືນຢັນຕົວຕົນດ້ວຍລະຫັດຜ່ານ

ເມື່ອຕິດຕັ້ງໂດຍໃຊ້ pip, ເຈົ້າສາມາດລະບຸຄຸນສົມບັດທີ່ຕ້ອງການໄດ້ໂດຍກົງເມື່ອຕິດຕັ້ງ:

uv pip install "weblate[Postgres,Amazon,SAML]"

ຫຼື ເຈົ້າສາມາດຕິດຕັ້ງ Weblate ດ້ວຍຄຸນສົມບັດເສີມທັງໝົດ:

uv pip install "weblate[all]"

ຫຼື ເຈົ້າສາມາດຕິດຕັ້ງ Weblate ໂດຍບໍ່ມີຄຸນສົມບັດເສີມໃດໆ:

uv pip install weblate

ການແກ້ໄຂບັນຫາ pip install¶

ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

ນີ້ເກີດຈາກຄວາມບໍ່ເຂົ້າກັນຂອງແພັກເກັດໄບນາຣີທີ່ແຈກຢາຍຜ່ານ PyPI ກັບການແຈກຢາຍ. ເພື່ອແກ້ໄຂສິ່ງນີ້, ເຈົ້າຈຳເປັນຕ້ອງສ້າງແພັກເກັດຄືນໃໝ່ໃນລະບົບຂອງເຈົ້າ:

uv pip install --force-reinstall --no-binary :all: cffi

error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?

ນີ້ແມ່ນບັນຫາທີ່ຮູ້ຈັກກັນດີຂອງແພັກເກັດ xmlsec, ກະລຸນາເບິ່ງ https://github.com/xmlsec/python-xmlsec/issues/314.

lxml & xmlsec libxml2 library version mismatch

ແພັກເກັດ lxml ແລະ xmlsec ຕ້ອງຖືກສ້າງຂຶ້ນໂດຍອີງໃສ່ libxml2 ອັນດຽວ. ເຈົ້າຄວນສ້າງພວກມັນໃນທ້ອງຖິ່ນເພື່ອຫຼີກລ່ຽງບັນຫານີ້:

uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec

ຄວາມຕ້ອງການລະບົບອື່ນໆ¶

Dependencies ຕໍ່ໄປນີ້ຕ້ອງຖືກຕິດຕັ້ງໃນລະບົບ:

Git: https://git-scm.com/
git-review (ເສີມສຳລັບການຮອງຮັບ Gerrit): git-review
git-svn (ເສີມສຳລັບການຮອງຮັບ Subversion): https://git-scm.com/docs/git-svn
tesseract (ຕ້ອງການກໍຕໍ່ເມື່ອ tesserocr binary wheels ບໍ່ມີໃຫ້ສຳລັບລະບົບຂອງເຈົ້າ): https://github.com/tesseract-ocr/tesseract

Dependencies ໃນເວລາສ້າງ (Build-time)¶

ເພື່ອສ້າງບາງ Python dependencies ເຈົ້າອາດຈະຕ້ອງຕິດຕັ້ງ dependencies ຂອງພວກມັນ. ສິ່ງນີ້ຂຶ້ນຢູ່ກັບວິທີທີ່ເຈົ້າຕິດຕັ້ງພວກມັນ, ສະນັ້ນກະລຸນາປຶກສາເອກະສານຂອງແພັກເກັດແຕ່ລະອັນ. ເຈົ້າຈະບໍ່ຕ້ອງການພວກມັນຖ້າໃຊ້ Wheels ທີ່ສ້າງໄວ້ລ່ວງໜ້າໃນຂະນະທີ່ຕິດຕັ້ງໂດຍໃຊ້ pip ຫຼື ເມື່ອເຈົ້າໃຊ້ແພັກເກັດການແຈກຢາຍ.

ຄວາມຕ້ອງການດ້ານຮາດແວ¶

Weblate ຄວນຈະຮັນໄດ້ເທິງຮາດແວສະໄໝໃໝ່ໂດຍບໍ່ມີບັນຫາ, ຕໍ່ໄປນີ້ແມ່ນການຕັ້ງຄ່າຂັ້ນຕ່ຳທີ່ຈຳເປັນເພື່ອຮັນ Weblate ເທິງໂຮສຕ໌ດຽວ (Weblate, ຖານຂໍ້ມູນ ແລະ ເວັບເຊີບເວີ):

RAM 3 GB
2 CPU cores
ພື້ນທີ່ຈັດເກັບຂໍ້ມູນ 1 GB

Note

ຄວາມຕ້ອງການທີ່ແທ້ຈິງສຳລັບການຕິດຕັ້ງ Weblate ຂອງທ່ານຈະແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍໂດຍອີງໃສ່ຂະໜາດຂອງການແປທີ່ຈັດການຢູ່ພາຍໃນນັ້ນ.

ການໃຊ້ງານໜ່ວຍຄວາມຈຳ¶

ມີໜ່ວຍຄວາມຈຳຫຼາຍເທົ່າໃດກໍຍິ່ງດີ - ມັນຖືກໃຊ້ສຳລັບການ caching ໃນທຸກລະດັບ (ລະບົບໄຟລ໌, ຖານຂໍ້ມູນ ແລະ Weblate). ສຳລັບສ່ວນປະກອບການແປຫຼາຍຮ້ອຍລາຍການ, ແນະນຳໃຫ້ມີ RAM ຢ່າງໜ້ອຍ 4 GB.

Hint

ສຳລັບລະບົບທີ່ມີໜ່ວຍຄວາມຈຳໜ້ອຍກວ່າທີ່ແນະນຳ, ແນະນຳໃຫ້ໃຊ້ ການຕັ້ງຄ່າ Celery ແບບ Single-process.

ການໃຊ້ງານ CPU¶

ຜູ້ໃຊ້ຫຼາຍຄົນທີ່ໃຊ້ງານພ້ອມກັນຈະເພີ່ມຈຳນວນ CPU cores ທີ່ຈຳເປັນ.

Weblate 2026.8 introduced NumPy as a required dependency. On x86-64 systems, the optimized NumPy build bundled in the Docker image requires an x86-64-v2 compatible CPU. Without the required CPU features, NumPy fails to load and Weblate cannot start.

Before upgrading, check for the required SSE4.2 CPU feature on the Linux system running Docker:

grep sse4_2 /proc/cpuinfo

Empty output indicates that a required CPU feature is unavailable. This is a preliminary check; finding SSE4.2 does not verify all x86-64-v2 CPU features.

If Docker runs in a virtual machine, run the check inside the guest. Virtual machines can hide CPU features supported by the host. Configure the virtual machine to expose the required host CPU features, then reboot the guest. If the physical CPU lacks the required features, upgrade the hardware.

ການໃຊ້ງານພື້ນທີ່ຈັດເກັບຂໍ້ມູນ¶

ການໃຊ້ພື້ນທີ່ຈັດເກັບຖານຂໍ້ມູນໂດຍທົ່ວໄປແມ່ນປະມານ 300 MB ຕໍ່ 1 ລ້ານຄຳທີ່ຝາກໄວ້.

ພື້ນທີ່ຈັດເກັບຂໍ້ມູນທີ່ຈຳເປັນສຳລັບ cloned repositories ຈະແຕກຕ່າງກັນ, ແຕ່ Weblate ພະຍາຍາມຮັກສາຂະໜາດຂອງມັນໃຫ້ໜ້ອຍທີ່ສຸດໂດຍການເຮັດ shallow clones.

Storage performance¶

ການດຳເນີນການຄວບຄຸມເວີຊັນມີການຄົ້ນຫາ metadata ຂອງລະບົບໄຟລ໌ຫຼາຍຄັ້ງ. ດັ່ງນັ້ນ ໂຟນເດີຍ່ອຍ vcs ໃນ DATA_DIR ຈຶ່ງຕ້ອງການຄວາມໜ່ວງໃນການອ່ານ (read latency) ທີ່ຕໍ່າ; ບ່ອນເກັບຂໍ້ມູນທີ່ມີ ການເຂົ້າເຖິງ metadata ຊ້າ ສາມາດເຮັດໃຫ້ການດຳເນີນການ ເຊັ່ນ git status ໃຊ້ເວລາດົນ ເຖິງແມ່ນວ່າຄວາມໄວໃນການຮັບສົ່ງຂໍ້ມູນໂດຍລວມຈະດີກໍຕາມ. ໃຫ້ເກັບ CACHE_DIR ໄວ້ໃນບ່ອນເກັບຂໍ້ມູນ ທ້ອງຖິ່ນ ຫຼື ຊົ່ວຄາວທີ່ມີຄວາມໜ່ວງຕໍ່າຫາກເປັນໄປໄດ້.

ການກວດສອບການຕິດຕັ້ງຈະວັດແທກຄວາມໜ່ວງໃນການຄົ້ນຫາ metadata ສຳລັບທັງສອງຕຳແໜ່ງ ແລະ ແຈ້ງເຕືອນ ເມື່ອຄວາມໜ່ວງສະເລ່ຍເກີນ 10 ມິນລິວິນາທີ. ນີ້ແມ່ນການວັດແທກໂດຍປະມານໃນຊ່ວງເວລາໃດໜຶ່ງ ເຊິ່ງໄດ້ຮັບຜົນກະທົບຈາກລະບົບໄຟລ໌ ແລະ ພາລະຂອງລະບົບ. ໃຫ້ລັນ weblate check --deploy ຄືນໃໝ່ກ່ອນທີ່ຈະປ່ຽນແປງການຕັ້ງຄ່າບ່ອນເກັບຂໍ້ມູນ.

Nodes¶

ສຳລັບເວັບໄຊຂະໜາດນ້ອຍ ແລະ ຂະໜາດກາງ (ຫຼາຍລ້ານຄຳທີ່ຝາກໄວ້), ສ່ວນປະກອບທັງໝົດຂອງ Weblate (ເບິ່ງ ພາບລວມຂອງສະຖາປັດຕະຍະກຳ) ສາມາດຮັນເທິງ node ດຽວໄດ້.

ເມື່ອທ່ານເຕີບໂຕໄປເຖິງຫຼາຍຮ້ອຍລ້ານຄຳທີ່ຝາກໄວ້, ແນະນຳໃຫ້ມີ node ສະເພາະສຳລັບຖານຂໍ້ມູນ (ເບິ່ງ ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate).

ການກວດສອບອະຕິເຟກ (artifacts) ການປ່ອຍເວີຊັນ¶

ອະໄຄບ໌ (archives) ການປ່ອຍເວີຊັນສາມາດຖືກກວດສອບໂດຍໃຊ້ລາຍເຊັນ, ການຮັບຮອງ, ແລະ SBOMs ທີ່ເຜີຍແຜ່ພ້ອມກັບຊັບສິນການປ່ອຍເວີຊັນ GitHub. ເບິ່ງ ການກວດສອບອະຕິເຟກ (artifacts) ການປ່ອຍເວີຊັນ.

ສິດທິລະບົບໄຟລ໌¶

ຂະບວນການ Weblate ຕ້ອງສາມາດອ່ານ ແລະ ຂຽນໄດເຣັກທໍຣີບ່ອນທີ່ມັນເກັບຂໍ້ມູນ - DATA_DIR. ໄຟລ໌ທັງໝົດພາຍໃນໄດເຣັກທໍຣີນີ້ຄວນເປັນເຈົ້າຂອງ ແລະ ສາມາດຂຽນໄດ້ໂດຍຜູ້ໃຊ້ທີ່ແລ່ນຂະບວນການ Weblate ທັງໝົດ (ປົກກະຕິຄື WSGI ແລະ Celery, ເບິ່ງ ການແລ່ນເຊີບເວີ ແລະ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery).

ການຕັ້ງຄ່າເລີ່ມຕົ້ນວາງພວກມັນໄວ້ໃນທຣີດຽວກັນກັບແຫຼ່ງ Weblate, ຢ່າງໃດກໍຕາມເຈົ້າອາດຕ້ອງການຍ້າຍພວກມັນໄປບ່ອນທີ່ດີກວ່າ ເຊັ່ນ: /var/lib/weblate.

Weblate ພະຍາຍາມສ້າງໄດເຣັກທໍຣີເຫຼົ່ານີ້ໂດຍອັດຕະໂນມັດ, ແຕ່ມັນຈະລົ້ມເຫຼວເມື່ອບໍ່ມີສິດທິໃນການເຮັດດັ່ງກ່າວ.

CACHE_DIR ທີ່ຕັ້ງຄ່າໄວ້ຍັງຕ້ອງສາມາດຂຽນໄດ້ໂດຍຂະບວນການ Weblate ແລະ ຕ້ອງອະນຸຍາດໃຫ້ປະຕິບັດໄຟລ໌ຊ່ວຍເຫຼືອທີ່ສ້າງຂຶ້ນ. ຢ່າເມົາທ໌ (mount) CACHE_DIR ດ້ວຍທາງເລືອກ noexec.

ເຈົ້າຍັງຄວນລະມັດລະວັງເມື່ອແລ່ນ ຄຳສັ່ງຈັດການ, ເພາະພວກມັນຄວນຖືກແລ່ນພາຍໃຕ້ຜູ້ໃຊ້ດຽວກັນກັບ Weblate, ຖ້າບໍ່ດັ່ງນັ້ນສິດທິໃນບາງໄຟລ໌ອາດຈະຜິດພາດ.

ໃນຄອນເທນເນີ Docker, ໄຟລ໌ທັງໝົດໃນໂວລຸມ /app/data ຕ້ອງເປັນເຈົ້າຂອງໂດຍຜູ້ໃຊ້ weblate ພາຍໃນຄອນເທນເນີ (UID 1000).

See also

ການໃຫ້ບໍລິການໄຟລ໌ Static

ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate¶

ແນະນຳໃຫ້ແລ່ນ Weblate ກັບເຊີບເວີຖານຂໍ້ມູນ PostgreSQL.

ຮອງຮັບ PostgreSQL 13 ແລະ ສູງກວ່າ. ແນະນຳ PostgreSQL 15 ຫຼື ໃໝ່ກວ່າ.

See also

ການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ¶

ໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນ, ແຕ່ລະຂະບວນການ Weblate ຈະຮັກສາການເຊື່ອມຕໍ່ແບບຖາວອນກັບຖານຂໍ້ມູນ. ການເຊື່ອມຕໍ່ແບບຖາວອນຈະຊ່ວຍປັບປຸງການຕອບສະໜອງຂອງ Weblate, ແຕ່ອາດຕ້ອງການຊັບພະຍາກອນເພີ່ມເຕີມສຳລັບເຊີບເວີຖານຂໍ້ມູນ. ກະລຸນາເບິ່ງ CONN_MAX_AGE ແລະ Persistent connections ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ.

Weblate ຕ້ອງການການເຊື່ອມຕໍ່ຢ່າງໜ້ອຍຕາມຈຳນວນນີ້:

$(4 \times \mathit{nCPUs}) + 2$ ສຳລັບຂະບວນການ Celery
$\mathit{nCPUs} + 1$ ສຳລັບ WSGI workers

ສິ່ງນີ້ໃຊ້ກັບຄ່າເລີ່ມຕົ້ນຂອງຄອນເທນເນີ Docker ແລະ ການຕັ້ງຄ່າຕົວຢ່າງທີ່ໃຫ້ໄວ້ໃນເອກະສານນີ້, ແຕ່ຕົວເລກຈະປ່ຽນແປງເມື່ອເຈົ້າປັບແຕ່ງຈຳນວນ WSGI workers ຫຼື ປັບຄວາມຂະໜານຂອງ Celery.

ຂີດຈຳກັດຕົວຈິງສຳລັບຈຳນວນການເຊື່ອມຕໍ່ຖານຂໍ້ມູນຕ້ອງສູງຂຶ້ນເພື່ອຮອງຮັບສະຖານະການຕໍ່ໄປນີ້:

ຄຳສັ່ງຈັດການ ຕ້ອງການການເຊື່ອມຕໍ່ຂອງພວກມັນເຊັ່ນກັນ.
ຖ້າຂະບວນການຖືກຂ້າ (ຕົວຢ່າງໂດຍ OOM killer), ມັນອາດຈະບລັອກການເຊື່ອມຕໍ່ທີ່ມີຢູ່ຈົນກວ່າຈະໝົດເວລາ.

PostgreSQL¶

PostgreSQL ປົກກະຕິແລ້ວແມ່ນທາງເລືອກທີ່ດີທີ່ສຸດສຳລັບເວັບໄຊທີ່ອີງໃສ່ Django. ມັນແມ່ນຖານຂໍ້ມູນອ້າງອີງທີ່ໃຊ້ສຳລັບການປະຕິບັດຊັ້ນຖານຂໍ້ມູນ Django.

Note

Weblate ໃຊ້ trigram extension ເຊິ່ງຕ້ອງຖືກຕິດຕັ້ງແຍກຕ່າງຫາກໃນບາງກໍລະນີ. ຊອກຫາ postgresql-contrib ຫຼື ແພັກເກັດທີ່ມີຊື່ຄ້າຍຄືກັນ.

See also

PostgreSQL notes

ການສ້າງຖານຂໍ້ມູນໃນ PostgreSQL¶

ປົກກະຕິແລ້ວມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະແລ່ນ Weblate ໃນຖານຂໍ້ມູນແຍກຕ່າງຫາກ, ແລະ ບັນຊີຜູ້ໃຊ້ແຍກຕ່າງຫາກ:

# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"

# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate

# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate

Hint

ຖ້າເຈົ້າບໍ່ຕ້ອງການເຮັດໃຫ້ຜູ້ໃຊ້ Weblate ເປັນ superuser ໃນ PostgreSQL, ເຈົ້າສາມາດລະເວັ້ນສິ່ງນັ້ນໄດ້. ໃນກໍລະນີນັ້ນ ເຈົ້າຈະຕ້ອງປະຕິບັດບາງຂັ້ນຕອນການຍ້າຍຖານຂໍ້ມູນ (migration) ດ້ວຍຕົນເອງໃນຖານະ superuser PostgreSQL ໃນສະຄີມາທີ່ Weblate ຈະໃຊ້:

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
CREATE EXTENSION IF NOT EXISTS btree_gist;

ການຕັ້ງຄ່າ Weblate ໃຫ້ໃຊ້ PostgreSQL¶

ສະນິບເປັດ (snippet) settings.py ສຳລັບ PostgreSQL:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Configures name of the PostgreSQL role to alter during the database migration
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
        # Persistent connections
        "CONN_MAX_AGE": None,
        "CONN_HEALTH_CHECKS": True,
    }
}

ການຍ້າຍຖານຂໍ້ມູນຈະປະຕິບັດ ALTER ROLE ບົດບາດຖານຂໍ້ມູນທີ່ໃຊ້ໂດຍ Weblate. ໃນກໍລະນີສ່ວນໃຫຍ່, ຊື່ຂອງບົດບາດຈະກົງກັບຊື່ຜູ້ໃຊ້. ໃນການຕັ້ງຄ່າທີ່ສັບສົນກວ່າ, ຊື່ບົດບາດຈະແຕກຕ່າງຈາກຊື່ຜູ້ໃຊ້, ແລະ ເຈົ້າຈະໄດ້ຮັບຂໍ້ຜິດພາດກ່ຽວກັບບົດບາດທີ່ບໍ່ມີຢູ່ລະຫວ່າງການຍ້າຍຖານຂໍ້ມູນ (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). ສິ່ງນີ້ເປັນທີ່ຮູ້ຈັກວ່າເກີດຂຶ້ນກັບ Azure Database ສຳລັບ PostgreSQL, ແຕ່ບໍ່ໄດ້ຈຳກັດພຽງແຕ່ສະພາບແວດລ້ອມນີ້. ກະລຸນາຕັ້ງຄ່າ ALTER_ROLE ເພື່ອປ່ຽນຊື່ຂອງບົດບາດທີ່ Weblate ຄວນປ່ຽນແປງໃນລະຫວ່າງການຍ້າຍຖານຂໍ້ມູນ.

See also

ການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ

ການຕັ້ງຄ່າອື່ນໆ¶

ການຕັ້ງຄ່າອີເມວຂາອອກ¶

Weblate ສົ່ງອີເມວໃນໂອກາດຕ່າງໆ - ສຳລັບການເປີດໃຊ້ບັນຊີ ແລະ ການແຈ້ງເຕືອນຕ່າງໆທີ່ຕັ້ງຄ່າໂດຍຜູ້ໃຊ້. ສຳລັບສິ່ງນີ້ ມັນຕ້ອງການການເຂົ້າເຖິງເຊີບເວີ SMTP.

ການຕັ້ງຄ່າເຊີບເວີອີເມວຖືກຕັ້ງຄ່າໂດຍໃຊ້ການຕັ້ງຄ່າເຫຼົ່ານີ້: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER ແລະ EMAIL_PORT. ຊື່ຂອງພວກມັນອະທິບາຍດ້ວຍຕົນເອງໄດ້ດີພໍສົມຄວນ, ແຕ່ເຈົ້າສາມາດພົບຂໍ້ມູນເພີ່ມເຕີມໄດ້ໃນເອກະສານ Django.

Hint

ໃນກໍລະນີທີ່ເຈົ້າໄດ້ຮັບຂໍ້ຜິດພາດກ່ຽວກັບການພິສູດຢືນຢັນທີ່ບໍ່ຮອງຮັບ (ຕົວຢ່າງ SMTP AUTH extension not supported by server), ມັນເກີດຈາກການໃຊ້ການເຊື່ອມຕໍ່ທີ່ບໍ່ປອດໄພ ແລະ ເຊີບເວີປະຕິເສດທີ່ຈະພິສູດຢືນຢັນດ້ວຍວິທີນີ້. ລອງເປີດໃຊ້ EMAIL_USE_TLS ໃນກໍລະນີນັ້ນ.

See also

ການແລ່ນຫຼັງຣີເວີສພຣອກຊີ (reverse proxy)¶

ຄຸນສົມບັດຫຼາຍຢ່າງໃນ Weblate ອີງໃສ່ຫົວຂໍ້ (headers) HTTP ທີ່ຖືກຕ້ອງທີ່ຖືກສົ່ງຕໍ່ໄປຍັງ Weblate. ເມື່ອໃຊ້ຣີເວີສພຣອກຊີ, ກະລຸນາຮັບປະກັນວ່າຂໍ້ມູນທີ່ຕ້ອງການຖືກສົ່ງຕໍ່ຢ່າງຖືກຕ້ອງ.

ເພື່ອດີບັຄ (debug) ການຕັ້ງຄ່ານີ້, ເຈົ້າສາມາດເບິ່ງ HTTP environment ໃນ ລາຍງານປະສິດທິພາບ.

ທີ່ຢູ່ IP ຂອງໄຄລເອັນທ໌

ສິ່ງນີ້ຈຳເປັນສຳລັບ ການຈຳກັດອັດຕາ ຫຼື ບັນທຶກການກວດສອບ.

Weblate ແຍກວິເຄາະທີ່ຢູ່ IP ຈາກ REMOTE_ADDR, ເຊິ່ງຖືກຕັ້ງຄ່າໂດຍ WSGI handler. ນີ້ອາດຈະຫວ່າງເປົ່າ (ເມື່ອໃຊ້ຊັອກເກັດສຳລັບ WSGI) ຫຼື ມີທີ່ຢູ່ຣີເວີສພຣອກຊີ, ສະນັ້ນ Weblate ຕ້ອງການຫົວຂໍ້ HTTP ເພີ່ມເຕີມພ້ອມກັບທີ່ຢູ່ IP ຂອງລູກຄ້າ.

ການເປີດໃຊ້ IP_BEHIND_REVERSE_PROXY ຄວນພຽງພໍສຳລັບການຕັ້ງຄ່າທົ່ວໄປທີ່ສຸດ, ແຕ່ເຈົ້າອາດຈະຕ້ອງປັບ IP_PROXY_HEADER ແລະ IP_PROXY_OFFSET ເຊັ່ນກັນ (ໃຊ້ WEBLATE_IP_PROXY_HEADER ແລະ WEBLATE_IP_PROXY_OFFSET ໃນຄອນເທນເນີ Docker).

Reverse proxy ທີ່ເຊື່ອມຕໍ່ກັບ Weblate ຕ້ອງຂຽນທັບສ່ວນຫົວທີ່ຕັ້ງຄ່າໄວ້ ຫຼື ຕໍ່ທ້າຍທີ່ຢູ່ peer ທີ່ຢືນຢັນແລ້ວໃນຕຳແໜ່ງທີ່ເລືອກໂດຍ IP_PROXY_OFFSET. ຫ້າມເລືອກທີ່ຢູ່ທີ່ລູກຄ້າສົ່ງມາ, ແລະ ຫ້າມເປີດເຜີຍເຊີບເວີແອັບພລິເຄຊັນຜ່ານເສັ້ນທາງທີ່ຂ້າມ proxy ທີ່ໜ້າເຊື່ອຖື.

ເມື່ອໃຊ້ X-Forwarded-For ກັບ Docker container, ໃຫ້ຕັ້ງຄ່າ WEBLATE_TRUSTED_PROXY_ADDRESSES ດ້ວຍ reverse proxies ທີ່ໄດ້ຮັບອະນຸຍາດໃຫ້ສົ່ງທີ່ຢູ່ຂອງລູກຄ້າ.

Hint

ການຕັ້ງຄ່ານີ້ບໍ່ສາມາດຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ, ເພາະມັນຈະອະນຸຍາດໃຫ້ມີການປອມແປງທີ່ຢູ່ IP ໃນການຕິດຕັ້ງທີ່ບໍ່ມີຣີເວີສພຣອກຊີທີ່ຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ.

ຊື່ໂຮສຂອງເຊີບເວີ

ຫົວຂໍ້ Host ຄວນກົງກັບສິ່ງໃດກໍຕາມທີ່ຖືກຕັ້ງຄ່າເປັນ SITE_DOMAIN. ການຕັ້ງຄ່າເພີ່ມເຕີມອາດຈຳເປັນໃນຣີເວີສພຣອກຊີຂອງເຈົ້າ (ຕົວຢ່າງໃຊ້ ProxyPreserveHost On ສຳລັບ Apache ຫຼື proxy_set_header Host $host; ກັບ nginx).

Hint

ຂໍ້ຜິດພາດການພິສູດຢືນຢັນ CSRF ລົ້ມເຫຼວມັກຈະເກີດຈາກຄວາມບໍ່ກົງກັນລະຫວ່າງຫົວຂໍ້ Host ແລະ SITE_DOMAIN ທີ່ຕັ້ງຄ່າໄວ້.

ໂປຣໂຕຄອນຂອງລູກຄ້າ

ການບໍ່ສົ່ງໂປຣໂຕຄອນທີ່ຖືກຕ້ອງອາດເຮັດໃຫ້ Weblate ຕົກຢູ່ໃນວົງຈອນການປ່ຽນເສັ້ນທາງ (redirection loop) ໂດຍພະຍາຍາມອັບເກຣດລູກຄ້າໄປຍັງ HTTPS. ໃຫ້ແນ່ໃຈວ່າວ່າມັນຖືກເປີດເຜີຍຢ່າງຖືກຕ້ອງໂດຍຣີເວີສພຣອກຊີເປັນ X-Forwarded-Proto.

ຫົວຂໍ້ນີ້ຈຳເປັນຕ້ອງຖືກຕັ້ງຄ່າໃນ SECURE_PROXY_SSL_HEADER (settings.py) ຫຼື WEBLATE_SECURE_PROXY_SSL_HEADER (ສະພາບແວດລ້ອມ Docker).

Important

ຄ່າຫົວຂໍ້ມີຄວາມອ່ອນໄຫວຕໍ່ຕົວພິມໃຫຍ່-ນ້ອຍໃນການຕັ້ງຄ່າ, ດັ່ງນັ້ນ WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,https ແລະ WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPS ບໍ່ສາມາດໃຊ້ແທນກັນໄດ້.

Hint

ຖ້າເຈົ້າໄດ້ຮັບຂໍ້ຜິດພາດ "Too many redirects" ຈາກບຣາວເຊີ, ມັນມັກຈະເກີດຈາກຄວາມບໍ່ກົງກັນລະຫວ່າງໂປຣໂຕຄອນຕົວຈິງ (HTTPS) ແລະ ສິ່ງທີ່ Weblate ສັງເກດເຫັນ.

Changed in version 5.13: ຫົວຂໍ້ພຣອກຊີໂປຣໂຕຄອນຖືກຈັດການໂດຍອັດຕະໂນມັດໂດຍ gunicorn ໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນ, ແຕ່ WSGI servers ອື່ນໆມີການຕັ້ງຄ່າທີ່ປອດໄພກວ່າ ແລະ ຕ້ອງການການຕັ້ງຄ່າສິ່ງນີ້ຢ່າງຈະແຈ້ງ.

ຕັ້ງແຕ່ Weblate 5.13 ຄອນເທນເນີ Docker ໄດ້ໃຊ້ granian ແລະ ປັດຈຸບັນມັນຕ້ອງການການຕັ້ງຄ່າຢ່າງຈະແຈ້ງຂອງ WEBLATE_SECURE_PROXY_SSL_HEADER.

See also

SSL terminating proxy
ການຈຳກັດອັດຕາ
ບັນທຶກການກວດສອບ
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Granian
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Gunicorn
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ uWSGI
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache ແລະ Gunicorn
IP_BEHIND_REVERSE_PROXY
IP_PROXY_HEADER
IP_PROXY_OFFSET
SECURE_PROXY_SSL_HEADER
WEBLATE_IP_PROXY_HEADER
WEBLATE_TRUSTED_PROXY_ADDRESSES
WEBLATE_IP_PROXY_OFFSET

HTTP proxy¶

Weblate ຮອງຮັບການຕັ້ງຄ່າ HTTP ພຣັອກຊີ ແຍກຕາມໂປຣໂຕຄໍ ສຳລັບຄຳຮ້ອງຂໍ HTTP ຂາອອກ ແລະ ຄັງເກັບ Git. ໃຫ້ກຳນົດຄ່າຕົວປ່ຽນສະພາບແວດລ້ອມພຣັອກຊີໃນ settings.py:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["https_proxy"] = "http://proxy.example.com:8080"

ຮອງຮັບສະເພາະ http_proxy ແລະ https_proxy ເທົ່ານັ້ນ. ຕົວປ່ຽນແບບທົ່ວໄປ ແລະ ແບບຂ້າມ ເຊັ່ນ all_proxy ແລະ no_proxy, ການຕັ້ງຄ່າພຣັອກຊີຂອງລະບົບປະຕິບັດການ, ແລະ ການຕັ້ງຄ່າພຣັອກຊີສະເພາະຂອງ VCS ແມ່ນບໍ່ຮອງຮັບ.

See also

ຕົວປ່ຽນສະພາບແວດລ້ອມ Proxy

ການປັບແຕ່ງການຕັ້ງຄ່າ¶

See also

ຕົວຢ່າງການຕັ້ງຄ່າ

ສຳເນົາ weblate/settings_example.py ໄປຍັງ weblate/settings.py ແລະ ປັບແຕ່ງມັນໃຫ້ກົງກັບການຕັ້ງຄ່າຂອງເຈົ້າ. ເຈົ້າອາດຈະຕ້ອງການປັບຕົວເລືອກຕໍ່ໄປນີ້:

ADMINS

ລາຍການຂອງຜູ້ບໍລິຫານເວັບໄຊທີ່ຈະໄດ້ຮັບການແຈ້ງເຕືອນເມື່ອມີບາງຢ່າງຜິດພາດ, ຕົວຢ່າງການແຈ້ງເຕືອນກ່ຽວກັບການລວມທີ່ລົ້ມເຫຼວ, ຫຼື ຂໍ້ຜິດພາດຂອງ Django.

ແບບຟອມຕິດຕໍ່ສົ່ງອີເມວຫາພວກເຂົາເຊັ່ນກັນ ເວັ້ນເສຍແຕ່ ADMINS_CONTACT ຈະຖືກຕັ້ງຄ່າ.

See also

ADMINS

ADMINS_CONTACT

ຕັ້ງຄ່າຜູ້ເບິ່ງແຍງລະບົບໃຫ້ຖືກຕ້ອງ

ALLOWED_HOSTS

ເຈົ້າຕ້ອງຕັ້ງຄ່ານີ້ເພື່ອລາຍຊື່ໂຮສທີ່ເວັບໄຊຂອງເຈົ້າຄວນໃຫ້ບໍລິການ. ຕົວຢ່າງ:
ALLOWED_HOSTS = ["demo.weblate.org"]
ທາງເລືອກອື່ນ ເຈົ້າສາມາດລວມ wildcard:
ALLOWED_HOSTS = ["*"]
See also

ALLOWED_HOSTS

WEBLATE_ALLOWED_HOSTS

ຕັ້ງຄ່າໂຮສທີ່ອະນຸຍາດ (Allowed hosts)

SESSION_ENGINE

ຕັ້ງຄ່າວິທີການເກັບຮັກສາເຊສຊັນ (sessions) ຂອງເຈົ້າ. ໃນກໍລະນີທີ່ເຈົ້າຮັກສາເຄື່ອງຈັກເບື້ອງຫຼັງຖານຂໍ້ມູນເລີ່ມຕົ້ນ, ເຈົ້າຄວນວາງຕາຕະລາງ: weblate clearsessions ເພື່ອລຶບຂໍ້ມູນເຊສຊັນທີ່ເກົ່າແກ້ອອກຈາກຖານຂໍ້ມູນ.

ຖ້າເຈົ້າກຳລັງໃຊ້ Valkey ຫຼື Redis ເປັນແຄຊ (ເບິ່ງ ຕັ້ງຄ່າແຄສ (cache)) ແນະນຳໃຫ້ໃຊ້ສຳລັບເຊສຊັນເຊັ່ນກັນ:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
See also

Configuring the session engine

SESSION_ENGINE

DATABASES

ການເຊື່ອມຕໍ່ກັບເຊີບເວີຖານຂໍ້ມູນ, ກະລຸນາກວດສອບເອກະສານຂອງ Django ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ.

See also

ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate

DATABASES

Databases

DEBUG

ປິດການໃຊ້ງານນີ້ສຳລັບເຊີບເວີການຜະລິດໃດກໍໄດ້. ດ້ວຍโໝດດີບັຄທີ່ເປີດໃຊ້, Django ຈະສະແດງ backtraces ໃນກໍລະນີທີ່ເກີດຂໍ້ຜິດພາດແກ່ຜູ້ໃຊ້, ເມື່ອເຈົ້າປິດມັນ, ຂໍ້ຜິດພາດຈະຖືກສົ່ງທາງອີເມວຫາ ADMINS (ເບິ່ງຂ້າງເທິງ).

โໝດດີບັຄຍັງເຮັດໃຫ້ Weblate ຊ້າລົງ, ເນື່ອງຈາກ Django ເກັບຂໍ້ມູນພາຍໃນຫຼາຍຂຶ້ນໃນກໍລະນີນີ້.

See also

DEBUG

ປິດໂໝດດີບັຄ

DEFAULT_FROM_EMAIL

ທີ່ຢູ່ຜູ້ສົ່ງອີເມວສຳລັບອີເມວຂາອອກ, ຕົວຢ່າງອີເມວການລົງທະບຽນ.

See also

DEFAULT_FROM_EMAIL

SECRET_KEY

ຄີທີ່ໃຊ້ໂດຍ Django ເພື່ອລົງນາມຂໍ້ມູນບາງຢ່າງໃນຄຸກກີ້, ເບິ່ງ ກຸນແຈລັບ (Secret key) ຂອງ Django ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ.

See also

SECRET_KEY

SERVER_EMAIL

ອີເມວທີ່ໃຊ້ເປັນທີ່ຢູ່ຜູ້ສົ່ງສຳລັບການສົ່ງອີເມວຫາຜູ້ບໍລິຫານ, ຕົວຢ່າງການແຈ້ງເຕືອນກ່ຽວກັບການລວມທີ່ລົ້ມເຫຼວ.

See also

SERVER_EMAIL

ການຕື່ມຖານຂໍ້ມູນ¶

ຫຼັງຈາກການຕັ້ງຄ່າຂອງເຈົ້າພ້ອມແລ້ວ, ເຈົ້າສາມາດແລ່ນ migrate ເພື່ອສ້າງໂຄງສ້າງຖານຂໍ້ມູນ. ປັດຈຸບັນເຈົ້າຄວນຈະສາມາດສ້າງໂຄງການການແປໂດຍໃຊ້ອິນເຕີເຟສຜູ້ບໍລິຫານ.

ເມື່ອເຈົ້າເຮັດສຳເລັດ, ເຈົ້າຍັງຄວນກວດສອບ Performance report ໃນອິນເຕີເຟສຜູ້ບໍລິຫານ, ເຊິ່ງຈະໃຫ້ຄຳແນະນຳກ່ຽວກັບການຕັ້ງຄ່າທີ່ອາດບໍ່ເໝາະສົມໃນເວັບໄຊຂອງເຈົ້າ.

See also

ການຕັ້ງຄ່າໃນການຜະລິດ (Production)¶

ສຳລັບການຕັ້ງຄ່າໃນການຜະລິດ ເຈົ້າຄວນດຳເນີນການປັບປ່ຽນທີ່ອະທິບາຍໄວ້ໃນພາກຕໍ່ໄປນີ້. ການຕັ້ງຄ່າທີ່ສຳຄັນທີ່ສຸດຈະກະຕຸ້ນການເຕືອນ, ເຊິ່ງຖືກຊີ້ບອກດ້ວຍເຄື່ອງໝາຍອັດສະເຈີຍ (exclamation mark) ໃນແຖບດ້ານເທິງຖ້າລັອກອິນເປັນ superuser:

ຍັງແນະນຳໃຫ້ກວດສອບການກວດສອບທີ່ກະຕຸ້ນໂດຍ Django (ເຖິງແມ່ນວ່າເຈົ້າອາດຈະບໍ່ຈຳເປັນຕ້ອງແກ້ໄຂທັງໝົດກໍຕາມ):

weblate check --deploy

ເຈົ້າຍັງສາມາດທົບທວນລາຍການກວດສອບດຽວກັນທີ່ ລາຍງານປະສິດທິພາບ ໃນ ອິນເຕີເຟດການຈັດການ.

See also

Deployment checklist

ປິດໂໝດດີບັຄ¶

ປິດໂໝດດີບັຄຂອງ Django (DEBUG) ໂດຍ:

DEBUG = False

ເມື່ອເປີດໂໝດແກ້ໄຂບັນຫາ (debug mode), Django ຈະເກັບບັນທຶກທຸກຄຳສັ່ງທີ່ໄດ້ດຳເນີນການ ແລະ ສະແດງປະຫວັດຄວາມຜິດພາດໃຫ້ຜູ້ໃຊ້ເຫັນ, ເຊິ່ງເປັນສິ່ງທີ່ບໍ່ຄວນມີໃນສະພາບແວດລ້ອມທີ່ໃຊ້ງານຈິງ.

See also

ການປັບແຕ່ງການຕັ້ງຄ່າ

ຕັ້ງຄ່າຜູ້ເບິ່ງແຍງລະບົບໃຫ້ຖືກຕ້ອງ¶

ຕັ້ງຄ່າທີ່ຢູ່ອີເມວຂອງຜູ້ເບິ່ງແຍງລະບົບໃນການຕັ້ງຄ່າ ADMINS ເພື່ອກຳນົດວ່າໃຜຈະເປັນຜູ້ຮັບອີເມວໃນກໍລະນີທີ່ເກີດບັນຫາຂຶ້ນກັບເຊີບເວີ, ຕົວຢ່າງ:

ADMINS = ("Your Name <your_email@example.com>",)

See also

ການປັບແຕ່ງການຕັ້ງຄ່າ

ຕັ້ງຄ່າໂດເມນຂອງເວັບໄຊໃຫ້ຖືກຕ້ອງ¶

ປັບຊື່ເວັບໄຊ ແລະ ໂດເມນໃນອິນເຕີເຟດຂອງຜູ້ເບິ່ງແຍງລະບົບ, ຖ້າບໍ່ດັ່ງນັ້ນລິ້ງໃນ RSS ຫຼື ອີເມວຢືນຢັນການລົງທະບຽນຈະໃຊ້ງານບໍ່ໄດ້. ສ່ວນນີ້ຖືກຕັ້ງຄ່າໂດຍໃຊ້ SITE_DOMAIN ເຊິ່ງຄວນລະບຸຊື່ໂດເມນຂອງເວັບໄຊ.

Changed in version 4.2: ກ່ອນການປ່ອຍເວີຊັ່ນ 4.2, ຈະໃຊ້ Django sites framework ແທນ, ກະລຸນາເບິ່ງ The “sites” framework.

See also

ຕັ້ງຄ່າໂຮສທີ່ອະນຸຍາດ (Allowed hosts)
ຕັ້ງຄ່າ HTTPS ໃຫ້ຖືກຕ້ອງ
SITE_DOMAIN
WEBLATE_SITE_DOMAIN
ENABLE_HTTPS

ຕັ້ງຄ່າ HTTPS ໃຫ້ຖືກຕ້ອງ¶

ແນະນຳຢ່າງຍິ່ງໃຫ້ໃຊ້ Weblate ໂດຍຜ່ານໂປຣໂຕຄໍ HTTPS ທີ່ມີການເຂົ້າລະຫັດ. ຫຼັງຈາກເປີດໃຊ້ງານແລ້ວ, ເຈົ້າຄວນຕັ້ງຄ່າ ENABLE_HTTPS ໃນສ່ວນການຕັ້ງຄ່າ:

ENABLE_HTTPS = True

Hint

ເຈົ້າອາດຈະຕ້ອງການຕັ້ງຄ່າ HSTS ນຳ, ເບິ່ງ SSL/HTTPS ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ.

See also

ENABLE_HTTPS
ຕັ້ງຄ່າໂຮສທີ່ອະນຸຍາດ (Allowed hosts)
ຕັ້ງຄ່າໂດເມນຂອງເວັບໄຊໃຫ້ຖືກຕ້ອງ

ຕັ້ງຄ່າ SECURE_HSTS_SECONDS ໃຫ້ຖືກຕ້ອງ¶

ຖ້າເວັບໄຊຂອງເຈົ້າໃຊ້ງານຜ່ານ SSL, ເຈົ້າຕ້ອງພິຈາລະນາຕັ້ງຄ່າ SECURE_HSTS_SECONDS ໃນໄຟລ໌ settings.py ເພື່ອເປີດໃຊ້ງານ HTTP Strict Transport Security. ໂດຍຄ່າເລີ່ມຕົ້ນແມ່ນ 0 ດັ່ງທີ່ສະແດງຢູ່ລຸ່ມນີ້.

SECURE_HSTS_SECONDS = 0

ຖ້າຕັ້ງຄ່າເປັນຕົວເລກທີ່ບໍ່ແມ່ນສູນ, django.middleware.security.SecurityMiddleware ຈະຕັ້ງຄ່າ header HTTP Strict Transport Security ໃສ່ໃນທຸກຄຳຕອບທີ່ຍັງບໍ່ທັນມີ.

Warning

ການຕັ້ງຄ່າສ່ວນນີ້ຜິດພາດອາດເຮັດໃຫ້ເວັບໄຊຂອງເຈົ້າໃຊ້ງານບໍ່ໄດ້ (ໃນໄລຍະເວລາໜຶ່ງ) ແລະ ແກ້ໄຂໄດ້ຍາກ. ກະລຸນາອ່ານເອກະສານ HTTP Strict Transport Security ກ່ອນ.

ໃຊ້ລະບົບຖານຂໍ້ມູນທີ່ມີປະສິດທິພາບ¶

ກະລຸນາໃຊ້ PostgreSQL ສຳລັບສະພາບແວດລ້ອມທີ່ໃຊ້ງານຈິງ, ເບິ່ງ ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ.
ໃຊ້ສະຖານທີ່ໃກ້ຄຽງສຳລັບການແລ່ນຖານຂໍ້ມູນເຊີບເວີ, ຖ້າບໍ່ດັ່ງນັ້ນປະສິດທິພາບຂອງເຄືອຂ່າຍ ຫຼື ຄວາມໜ້າເຊື່ອຖືອາດເຮັດໃຫ້ປະສົບການການໃຊ້ງານ Weblate ບໍ່ດີ.
ກວດສອບປະສິດທິພາບຂອງຖານຂໍ້ມູນ ຫຼື ປັບແຕ່ງການຕັ້ງຄ່າ, ຕົວຢ່າງໂດຍການໃຊ້ PGTune.
ການກວດສອບການຕິດຕັ້ງ Weblate ລາຍງານສະຖິຕິຄວາມສຳພັນຂອງ PostgreSQL ທີ່ບໍ່ສິ້ນສຸດ. ໃຫ້ລັນຄຳສັ່ງ ANALYZE ໃນຄວາມສຳພັນທີ່ຖືກລາຍງານ ເພື່ອສ້າງສະຖິຕິທີ່ເສຍຫາຍຄືນໃໝ່.

See also

ຕັ້ງຄ່າແຄສ (cache)¶

ຖ້າເປັນໄປໄດ້, ໃຫ້ໃຊ້ Valkey ຫຼື Redis ຈາກ Django ໂດຍການປັບຕົວປ່ຽນການຕັ້ງຄ່າ CACHES, ຕົວຢ່າງ:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/0",
        # If redis is running on same host as Weblate, you might
        # want to use unix sockets instead:
        # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    }
}

Hint

ໃນກໍລະນີທີ່ເຈົ້າປ່ຽນການຕັ້ງຄ່າແຄສ, ເຈົ້າອາດຈຳເປັນຕ້ອງປັບການຕັ້ງຄ່າສຳລັບ Celery ນຳ, ເບິ່ງ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery.

See also

ການແຄສຮູບໂປຣໄຟລ໌ (Avatar)
Django’s cache framework

ການແຄສຮູບໂປຣໄຟລ໌ (Avatar)¶

ນອກຈາກການແຄສຂອງ Django ແລ້ວ, Weblate ຍັງມີການແຄສຮູບໂປຣໄຟລ໌. ແນະນຳໃຫ້ໃຊ້ແຄສແຍກຕ່າງຫາກທີ່ເກັບໄວ້ໃນໄຟລ໌ສຳລັບຈຸດປະສົງນີ້:

CACHES = {
    "default": {
        # Default caching backend setup, see above
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "unix:///var/run/redis/redis.sock?db=0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    },
    "avatar": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
        "TIMEOUT": 604800,
        "OPTIONS": {
            "MAX_ENTRIES": 1000,
        },
    },
}

See also

ຕັ້ງຄ່າການສົ່ງອີເມວ¶

Weblate ຈຳເປັນຕ້ອງສົ່ງອີເມວໃນຫຼາຍໆໂອກາດ, ແລະ ອີເມວເຫຼົ່ານີ້ຄວນມີທີ່ຢູ່ຜູ້ສົ່ງທີ່ຖືກຕ້ອງ, ກະລຸນາຕັ້ງຄ່າ SERVER_EMAIL ແລະ DEFAULT_FROM_EMAIL ໃຫ້ກົງກັບສະພາບແວດລ້ອມຂອງທ່ານ, ຕົວຢ່າງ:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

Note

ເພື່ອປິດການສົ່ງອີເມວໂດຍ Weblate, ໃຫ້ຕັ້ງຄ່າ EMAIL_BACKEND ເປັນ django.core.mail.backends.dummy.EmailBackend.

ການຕັ້ງຄ່ານີ້ຈະປິດການສົ່ງອີເມວ ທັງໝົດ ລວມທັງອີເມວການລົງທະບຽນ ຫຼື ການຣີເຊັດລະຫັດຜ່ານ.

See also

ການປັບແຕ່ງການຕັ້ງຄ່າ
ການຕັ້ງຄ່າອີເມວຂາອອກ
EMAIL_BACKEND
DEFAULT_FROM_EMAIL
SERVER_EMAIL

ຕັ້ງຄ່າໂຮສທີ່ອະນຸຍາດ (Allowed hosts)¶

Django ຮຽກຮ້ອງໃຫ້ ALLOWED_HOSTS ມີລາຍຊື່ຂອງຊື່ໂດເມນທີ່ເວັບໄຊຂອງເຈົ້າອະນຸຍາດໃຫ້ບໍລິການ, ການປ່ອຍຫວ່າງໄວ້ຈະເຮັດໃຫ້ທຸກຄຳຮ້ອງຂໍຖືກບລັອກ.

ໃນກໍລະນີທີ່ບໍ່ໄດ້ຕັ້ງຄ່າໃຫ້ກົງກັບ HTTP ເຊີບເວີຂອງທ່ານ, ເຈົ້າຈະໄດ້ຮັບຂໍ້ຜິດພາດເຊັ່ນ Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.

Hint

ໃນ Docker container, ສາມາດຕັ້ງຄ່າໄດ້ໂດຍຜ່ານ WEBLATE_ALLOWED_HOSTS.

See also

ALLOWED_HOSTS
WEBLATE_ALLOWED_HOSTS
ຕັ້ງຄ່າໂດເມນຂອງເວັບໄຊໃຫ້ຖືກຕ້ອງ

ກຸນແຈລັບ (Secret key) ຂອງ Django¶

ການຕັ້ງຄ່າ SECRET_KEY ຖືກໃຊ້ໂດຍ Django ເພື່ອເຊັນຄຸກກີ້, ເຈົ້າຄວນສ້າງຄ່າຂອງທ່ານເອງແທນທີ່ຈະໃຊ້ຄ່າຈາກການຕັ້ງຄ່າຕົວຢ່າງ.

ເຈົ້າສາມາດສ້າງກຸນແຈໃໝ່ໂດຍໃຊ້ weblate-generate-secret-key ທີ່ມາພ້ອມກັບ Weblate.

See also

SECRET_KEY

ການແລ່ນວຽກງານບຳລຸງຮັກສາ¶

ເພື່ອປະສິດທິພາບທີ່ດີທີ່ສຸດ, ມັນເປັນການດີທີ່ຈະແລ່ນວຽກງານບຳລຸງຮັກສາບາງຢ່າງໃນເບື້ອງຫຼັງ. ສິ່ງນີ້ຈະຖືກເຮັດໂດຍອັດຕະໂນມັດໂດຍ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery ແລະ ກວມເອົາວຽກງານຕໍ່ໄປນີ້:

ການກວດສອບຄວາມພ້ອມຂອງການຕັ້ງຄ່າ (ທຸກຊົ່ວໂມງ).
ການຄອມມິດການປ່ຽນແປງທີ່ຄ້າງໄວ້ (ທຸກຊົ່ວໂມງ), ເບິ່ງ Lazy commits ແລະ commit_pending.
ການອັບເດດການແຈ້ງເຕືອນຂອງອົງປະກອບ (ທຸກວັນ).
ການອັບເດດສາຂາຣີໂມດ (ທຸກຄືນ), ເບິ່ງ AUTO_UPDATE.
ການສຳຮອງຂໍ້ມູນ Translation memory ເປັນໄຟລ໌ JSON (ທຸກວັນ), ເບິ່ງ dump_memory.
ວຽກງານບຳລຸງຮັກສາຖານຂໍ້ມູນ ແລະ Fulltext (ວຽກງານປະຈຳວັນ ແລະ ປະຈຳອາທິດ), ເບິ່ງ cleanuptrans.

ລະບົບ Locale ແລະ ການເຂົ້າລະຫັດ¶

Locale ຂອງລະບົບຄວນຕັ້ງຄ່າເປັນແບບທີ່ຮອງຮັບ UTF-8. ໃນ Linux ສ່ວນໃຫຍ່ ນີ້ແມ່ນການຕັ້ງຄ່າເລີ່ມຕົ້ນ. ໃນກໍລະນີທີ່ລະບົບຂອງທ່ານບໍ່ແມ່ນ, ກະລຸນາປ່ຽນ Locale ເປັນແບບ UTF-8.

ຕົວຢ່າງໂດຍການແກ້ໄຂໄຟລ໌ /etc/default/locale ແລະ ຕັ້ງຄ່າ LANG="C.UTF-8".

ໃນບາງກໍລະນີ ບໍລິການແຕ່ລະຢ່າງຈະມີການຕັ້ງຄ່າ Locale ແຍກຕ່າງຫາກ. ສິ່ງນີ້ແຕກຕ່າງກັນໄປຕາມແຕ່ລະ Distribution ແລະ ເວັບເຊີບເວີ, ສະນັ້ນໃຫ້ກວດສອບເອກະສານຂອງແພັກເກດເວັບເຊີບເວີຂອງທ່ານ.

Apache ເທິງ Ubuntu ໃຊ້ /etc/apache2/envvars:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Apache ເທິງ CentOS ໃຊ້ /etc/sysconfig/httpd (ຫຼື /opt/rh/httpd24/root/etc/sysconfig/httpd):

LANG='en_US.UTF-8'

ການໃຊ້ Custom certificate authority¶

Weblate ຈະກວດສອບໃບຢັ້ງຢືນ SSL ໃນລະຫວ່າງການຮ້ອງຂໍ HTTP. ການຮ້ອງຂໍທີ່ໃຊ້ HTTPX2 ຈະໃຊ້ບ່ອນເກັບໃບຢັ້ງຢືນຂອງລະບົບ, ດັ່ງນັ້ນໃຫ້ຕິດຕັ້ງໃບຢັ້ງຢືນ CA ທີ່ກຳນົດເອງໄວ້ທີ່ນັ້ນ.

ກວດສອບເອກະສານຂອງລະບົບປະຕິບັດການທີ່ທ່ານໃຊ້ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ. ຕົວຢ່າງ: ໃນ Debian ທ່ານສາມາດເຮັດໄດ້ໂດຍການວາງໃບຢັ້ງຢືນ CA ໄວ້ໃນ /usr/local/share/ca-certificates/ ແລະ ຣັນຄຳສັ່ງ update-ca-certificates.

Hint

Weblate container ບໍ່ໄດ້ລວມເອົາມັນໄວ້ໃນເສັ້ນທາງການຊອກຫາ, ເຈົ້າຈຳເປັນຕ້ອງລະບຸເສັ້ນທາງເຕັມເພື່ອແລ່ນມັນ. ຕົວຢ່າງ:

docker compose exec -u root weblate /usr/sbin/update-ca-certificates

ເມື່ອສຳເລັດແລ້ວ, ການຮ້ອງຂໍຜ່ານ Weblate HTTPX2 ແລະ ເຄື່ອງມືຂອງລະບົບ ລວມທັງ Git ຈະໃຫ້ຄວາມເຊື່ອຖືຕໍ່ໃບຢັ້ງຢືນນັ້ນ.

ການເຊື່ອມຕໍ່ບາງຢ່າງ, ລວມທັງການຢືນຢັນຕົວຕົນ OAuth ແລະ OpenID Connect, ໃຊ້ Requests ເຊິ່ງໂດຍເລີ່ມຕົ້ນແລ້ວຈະບໍ່ໃຊ້ບ່ອນເກັບໃບຮັບຮອງຂອງລະບົບ. ເມື່ອການເຊື່ອມຕໍ່ເຫຼົ່ານີ້ຕິດຕໍ່ສື່ສານກັບບໍລິການ ທີ່ໃຊ້ໃບຮັບຮອງແບບກຳນົດເອງ (custom CA), ໃຫ້ຕັ້ງຄ່າ Requests ໃຫ້ໃຊ້ຊຸດ CA ຂອງລະບົບ ໂດຍການເພີ່ມຂໍ້ຄວາມຕໍ່ໄປນີ້ໃສ່ settings.py (ເສັ້ນທາງນີ້ແມ່ນສະເພາະສຳລັບ Debian):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

ການແລ່ນເຊີບເວີ¶

Hint

ໃນກໍລະນີທີ່ເຈົ້າບໍ່ມີປະສົບການກັບບໍລິການທີ່ອະທິບາຍຢູ່ລຸ່ມນີ້, ເຈົ້າອາດຈະຢາກລອງໃຊ້ ການຕິດຕັ້ງໂດຍໃຊ້ Docker.

ເຈົ້າຈະຕ້ອງມີຫຼາຍບໍລິການເພື່ອແລ່ນ Weblate, ການຕັ້ງຄ່າທີ່ແນະນຳປະກອບດ້ວຍ:

ຖານຂໍ້ມູນເຊີບເວີ (ເບິ່ງ ການຕັ້ງຄ່າຖານຂໍ້ມູນສຳລັບ Weblate)
ແຄສເຊີບເວີ (ເບິ່ງ ຕັ້ງຄ່າແຄສ (cache))
Frontend web server ສຳລັບໄຟລ໌ Static ແລະ SSL termination (ເບິ່ງ ການໃຫ້ບໍລິການໄຟລ໌ Static)
WSGI server ສຳລັບເນື້ອຫາ Dynamic (ເບິ່ງ ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ uWSGI)
Celery ສຳລັບດຳເນີນການວຽກງານເບື້ອງຫຼັງ (ເບິ່ງ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery)

Note

ມີການເພິ່ງພາອາໄສກັນລະຫວ່າງບໍລິການເຫຼົ່ານີ້, ຕົວຢ່າງ Cache ແລະ ຖານຂໍ້ມູນຄວນຈະແລ່ນຢູ່ເມື່ອເລີ່ມຕົ້ນ Celery ຫຼື uwsgi processes.

ໃນກໍລະນີສ່ວນໃຫຍ່, ເຈົ້າຈະແລ່ນທຸກບໍລິການເທິງເຊີບເວີ (virtual) ດຽວ, ແຕ່ໃນກໍລະນີທີ່ການຕິດຕັ້ງຂອງທ່ານມີການໃຊ້ງານໜັກ, ເຈົ້າສາມາດແຍກບໍລິການອອກໄດ້. ຂໍ້ຈຳກັດດຽວຄື Celery ແລະ Wsgi servers ຕ້ອງການການເຂົ້າເຖິງ DATA_DIR.

Note

WSGI process ຕ້ອງຖືກແລ່ນພາຍໃຕ້ User ດຽວກັນກັບ Celery process, ຖ້າບໍ່ດັ່ງນັ້ນໄຟລ໌ໃນ DATA_DIR ຈະຖືກຈັດເກັບດ້ວຍ Ownership ທີ່ປົນເປກັນ, ເຮັດໃຫ້ເກີດບັນຫາໃນລະຫວ່າງການໃຊ້ງານ.

ເບິ່ງເພີ່ມເຕີມ ສິດທິລະບົບໄຟລ໌ ແລະ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery.

ການແລ່ນເວັບເຊີບເວີ¶

ການແລ່ນ Weblate ບໍ່ແຕກຕ່າງຈາກການແລ່ນໂປຣແກຣມອື່ນທີ່ໃຊ້ Django. ປົກກະຕິ Django ຈະຖືກແລ່ນເປັນ WSGI ຫຼື fcgi (ເບິ່ງຕົວຢ່າງສຳລັບເວັບເຊີບເວີຕ່າງໆຢູ່ລຸ່ມນີ້).

Note

ໄຟລ໌ການຕັ້ງຄ່າຕົວຢ່າງທີ່ສະແດງຢູ່ລຸ່ມນີ້ຖືກເບິ່ງແຍງຢູ່ໃນ Weblate source tree ພາຍໃຕ້ weblate/examples/. ພວກມັນຖືກລວມຢູ່ໃນ Source distributions ແລະ ໃນເອກະສານນີ້, ແຕ່ Python wheels ຈະຕິດຕັ້ງສະເພາະໄຟລ໌ Runtime ເທົ່ານັ້ນ. ເມື່ອຕິດຕັ້ງ Weblate ຈາກ PyPI, ໃຫ້ດາວໂຫຼດ Source distribution ຫຼື Source checkout ທີ່ກົງກັນກ່ອນຈະກັອບປີ້ຕົວຢ່າງເຫຼົ່ານີ້.

ສຳລັບຈຸດປະສົງໃນການທົດສອບ, ເຈົ້າສາມາດໃຊ້ Built-in web server ໃນ Django ໄດ້:

weblate runserver

Warning

ຢ່າໃຊ້ເຊີບເວີນີ້ໃນສະພາບແວດລ້ອມທີ່ໃຊ້ງານຈິງ (Production). ມັນຍັງບໍ່ທັນຜ່ານການກວດສອບຄວາມປອດໄພ ຫຼື ການທົດສອບປະສິດທິພາບ. ເບິ່ງເພີ່ມເຕີມໃນເອກະສານ Django ກ່ຽວກັບ runserver.

Hint

Django built-in server ຈະໃຫ້ບໍລິການໄຟລ໌ Static ເມື່ອເປີດ DEBUG ເທົ່ານັ້ນ ເນື່ອງຈາກມັນມີໄວ້ສຳລັບການພັດທະນາເທົ່ານັ້ນ. ສຳລັບການໃຊ້ງານຈິງ, ກະລຸນາເບິ່ງການຕັ້ງຄ່າ WSGI:

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Granian
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Gunicorn
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ uWSGI
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache ແລະ Gunicorn
ການໃຫ້ບໍລິການໄຟລ໌ Static

ການໃຫ້ບໍລິການໄຟລ໌ Static¶

Changed in version 5.15.2: /media/ ບໍ່ຖືກໃຊ້ສຳລັບການໃຫ້ບໍລິການ Screenshot ອີກຕໍ່ໄປ.

Django ຈຳເປັນຕ້ອງລວບລວມໄຟລ໌ static ໄວ້ໃນໂຟນເດີດຽວ. ເພື່ອເຮັດສິ່ງນີ້, ໃຫ້ຣັນຄຳສັ່ງ weblate collectstatic --noinput. ນີ້ຈະສຳເນົາໄຟລ໌ static ໄປໄວ້ໃນໂຟນເດີທີ່ລະບຸໂດຍການຕັ້ງຄ່າ STATIC_ROOT (ຄ່າເລີ່ມຕົ້ນແມ່ນໂຟນເດີ static ພາຍໃນ CACHE_DIR). ການຕິດຕັ້ງເພື່ອໃຊ້ງານຈິງຈະໃຊ້ content hashes ໃນຊື່ໄຟລ໌ທີ່ລວບລວມ ເພື່ອບໍ່ໃຫ້ assets ທີ່ອັບເດດໃໝ່ໄປໃຊ້ cache ເກົ່າໃນບຣາວເຊີ ຫຼື proxy.

ແນະນຳໃຫ້ໃຫ້ບໍລິການໄຟລ໌ Static ໂດຍກົງຈາກເວັບເຊີບເວີຂອງທ່ານ, ເຈົ້າຄວນໃຊ້ສິ່ງນີ້ສຳລັບ Path ຕໍ່ໄປນີ້:

/static/: ໃຫ້ບໍລິການໄຟລ໌ Static ສຳລັບ Weblate ແລະ ອິນເຕີເຟດຜູ້ເບິ່ງແຍງລະບົບ (ຈາກທີ່ກຳນົດໄວ້ໃນ STATIC_ROOT).
/favicon.ico: ຄວນຖືກ Rewrite ເພື່ອໃຫ້ບໍລິການ /static/favicon.ico.

See also

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Granian
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Gunicorn
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ uWSGI
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache
ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache ແລະ Gunicorn
How to deploy Django
How to deploy static files

ນະໂຍບາຍຄວາມປອດໄພຂອງເນື້ອຫາ (Content security policy)¶

ການຕັ້ງຄ່າເລີ່ມຕົ້ນຂອງ Weblate ຈະເປີດໃຊ້ weblate.middleware.SecurityMiddleware ເຊິ່ງຈະຕັ້ງຄ່າ HTTP headers ທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພ ເຊັ່ນ Content-Security-Policy ຫຼື X-XSS-Protection. ໂດຍຄ່າເລີ່ມຕົ້ນ ພວກມັນຖືກຕັ້ງໄວ້ເພື່ອໃຫ້ເຮັດວຽກກັບ Weblate ແລະ ການຕັ້ງຄ່າຂອງມັນ, ແຕ່ອາດຈະຕ້ອງປັບແຕ່ງຕາມສະພາບແວດລ້ອມຂອງທ່ານ.

See also

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Granian¶

ການຕັ້ງຄ່າຕໍ່ໄປນີ້ຈະແລ່ນ Weblate ໂດຍໃຊ້ Granian ກັບ NGINX webserver:

weblate/examples/weblate.nginx.granian.conf¶

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        expires 30d;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8888;
        proxy_read_timeout 3600;
    }
}

See also

ການຕັ້ງຄ່າຕົວຢ່າງເພື່ອເລີ່ມຕົ້ນ Granian
https://github.com/emmett-framework/granian
How to deploy with WSGI

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ Gunicorn¶

ການຕັ້ງຄ່າຕໍ່ໄປນີ້ຈະແລ່ນ Weblate ໂດຍໃຊ້ Gunicorn ພາຍໃຕ້ NGINX webserver (weblate/examples/weblate.nginx.gunicorn.conf ໃນ Source tree):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        expires 30d;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://unix:/run/gunicorn.sock;
        proxy_read_timeout 3600;
    }
}

See also

ການຕັ້ງຄ່າຕົວຢ່າງເພື່ອເລີ່ມຕົ້ນ Gunicorn
How to use Django with Gunicorn

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ NGINX ແລະ uWSGI¶

ເພື່ອແລ່ນເວັບເຊີບເວີສຳລັບ Production, ໃຫ້ໃຊ້ WSGI wrapper ທີ່ຕິດຕັ້ງມາກັບ Weblate (ເມື່ອໃຊ້ Python environment ມັນຈະຖືກຕິດຕັ້ງຢູ່ ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). ຢ່າລືມຕັ້ງຄ່າ Python search path ໃຫ້ກົງກັບ Python environment ຂອງທ່ານນຳ (ຕົວຢ່າງໂດຍໃຊ້ virtualenv = /home/user/weblate-env ໃນ uWSGI).

ການຕັ້ງຄ່າຕໍ່ໄປນີ້ຈະແລ່ນ Weblate ເປັນ uWSGI ພາຍໃຕ້ NGINX webserver.

ການຕັ້ງຄ່າສຳລັບ NGINX (weblate/examples/weblate.nginx.conf ໃນ Source tree):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

ການຕັ້ງຄ່າສຳລັບ uWSGI (weblate/examples/weblate.uwsgi.ini ໃນ Source tree):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py

# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path   = /path/to/weblate

# Path to the Python environment
virtualenv = /home/weblate/weblate-env

# Set sys.executable so Python helpers run with the virtual environment's Python
py-executable = /home/weblate/weblate-env/bin/python

# Needed for OAuth/OpenID
buffer-size   = 8192

# Reload when consuming too much of memory
reload-on-rss = 250

# Increase number of workers for heavily loaded sites
workers       = 8

# Enable threads for Sentry error submission
enable-threads = true

# Child processes do not need file descriptors
close-on-exec = true

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true

# Enable uWSGI stats server
# stats = :1717
# stats-http = true

# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

Set py-executable to the absolute path of bin/python inside the environment configured by virtualenv. Weblate uses Python's sys.executable to launch helper processes, including the SSH connection proxy used for Git repositories. uWSGI can otherwise set this value to its own executable, causing repository operations to fail with an error such as /usr/bin/uwsgi-core: invalid option -- 'I'. Setting virtualenv alone does not ensure that sys.executable points to Python. Restart uWSGI after updating the configuration.

See also

How to use Django with uWSGI

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache¶

ແນະນຳໃຫ້ໃຊ້ Prefork MPM ເມື່ອໃຊ້ WSGI ກັບ Weblate.

ການຕັ້ງຄ່າຕໍ່ໄປນີ້ຈະແລ່ນ Weblate ເປັນ WSGI, ເຈົ້າຕ້ອງເປີດໃຊ້ mod_wsgi ກ່ອນ (weblate/examples/apache.conf ໃນ Source tree):

#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        Require all granted
    </Directory>

    # Path to your Weblate Python environment
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Note

Weblate ຕ້ອງການ Python 3, ສະນັ້ນກະລຸນາຮັບປະກັນວ່າເຈົ້າກຳລັງແລ່ນ modwsgi ຮຸ່ນ Python 3. ປົກກະຕິແລ້ວມັນຈະມີເປັນແພັກເກດແຍກຕ່າງຫາກ, ຕົວຢ່າງ libapache2-mod-wsgi-py3.

ໃຊ້ Python version ທີ່ກົງກັນເພື່ອຕິດຕັ້ງ Weblate.

See also

ລະບົບ Locale ແລະ ການເຂົ້າລະຫັດ
How to use Django with Apache and mod_wsgi

ການຕັ້ງຄ່າຕົວຢ່າງສຳລັບ Apache ແລະ Gunicorn¶

ການຕັ້ງຄ່າຕໍ່ໄປນີ້ຈະແລ່ນ Weblate ໃນ Gunicorn ແລະ Apache 2.4 (weblate/examples/apache.gunicorn.conf ໃນ Source tree):

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /favicon.ico !
    ProxyPass /static/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

See also

ການຕັ້ງຄ່າຕົວຢ່າງເພື່ອເລີ່ມຕົ້ນ Gunicorn
How to use Django with Gunicorn

ການຕັ້ງຄ່າຕົວຢ່າງເພື່ອເລີ່ມຕົ້ນ Granian¶

Weblate ມີ Optional dependency ຊື່ wsgi (ເບິ່ງ Python dependencies) ເຊິ່ງຈະຕິດຕັ້ງທຸກຢ່າງທີ່ເຈົ້າຕ້ອງການເພື່ອແລ່ນ Granian. ເມື່ອຕິດຕັ້ງ Weblate ເຈົ້າສາມາດລະບຸໄດ້ດັ່ງນີ້:

uv pip install Weblate[all,wsgi]

ເມື່ອຕິດຕັ້ງ Granian ແລ້ວ, ເຈົ້າສາມາດແລ່ນມັນໄດ້. ປົກກະຕິແລ້ວຈະເຮັດໃນລະດັບລະບົບ. ຕົວຢ່າງຕໍ່ໄປນີ້ສະແດງການເລີ່ມຕົ້ນຜ່ານ systemd:

/etc/systemd/system/granian.service¶

[Unit]
Description=granian daemon
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
    --no-ws \
    --workers-max-rss 450 \
    --interface wsgi \
    --workers 2 \
    --blocking-threads 8 \
    --backlog 128 \
    --backpressure 16 \
    --runtime-mode mt \
    --port 8888 \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target

Granian ໃຊ້ຂະບວນການ worker ສຳລັບການປະມວນຜົນ Python ແບບຂະໜານ, ໃຊ້ blocking threads ສຳລັບການຮ້ອງຂໍ WSGI ພ້ອມກັນ, ແລະ runtime threads ສຳລັບ network I/O. ຕົວຢ່າງນີ້ໃຊ້ສອງ workers ໂດຍມີແປດ blocking threads ແຕ່ລະອັນ, ຈຳກັດແຕ່ລະ worker ຢູ່ທີ່ 16 ການເຊື່ອມຕໍ່ພ້ອມກັນ, ແລະ ປ່ອຍໃຫ້ runtime threads ເປັນໄປຕາມຄ່າເລີ່ມຕົ້ນຂອງ Granian. ປັບປ່ຽນ workers ແລະ blocking threads ໃຫ້ເໝາະສົມກັບໜ່ວຍຄວາມຈຳ, CPU cores, ແລະ ຂີດຈຳກັດການເຊື່ອມຕໍ່ຖານຂໍ້ມູນທີ່ມີຢູ່. ໃຫ້ຮັກສາຄ່າ backpressure ໃຫ້ເທົ່າກັບ ຫຼື ສູງກວ່າຈຳນວນຂອງ blocking threads.

See also

ຕົວຢ່າງການຕັ້ງຄ່າເພື່ອເລີ່ມຕົ້ນ Granian ດ້ວຍ ASGI
https://github.com/emmett-framework/granian
How to deploy with WSGI

ຕົວຢ່າງການຕັ້ງຄ່າເພື່ອເລີ່ມຕົ້ນ Granian ດ້ວຍ ASGI¶

Added in version 2026.8.

ການຕິດຕັ້ງແບບ ASGI ມີໃຫ້ເລືອກໃຊ້ແທນ WSGI. ໃຫ້ຕິດຕັ້ງໄຟລ໌ທີ່ຈຳເປັນ (dependency) ເພີ່ມເຕີມສຳລັບ asgi:

uv pip install Weblate[all,asgi]

ຊຸດ systemd ຕໍ່ໄປນີ້ແມ່ນໃຊ້ລັນແອັບພລິເຄຊັນ Django ASGI:

/etc/systemd/system/granian-asgi.service¶

[Unit]
Description=granian ASGI daemon
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
    --no-ws \
    --workers-max-rss 450 \
    --interface asginl \
    --workers 2 \
    --backlog 128 \
    --backpressure 16 \
    --runtime-mode mt \
    --port 8888 \
    weblate.asgi:application

[Install]
WantedBy=multi-user.target

ຕົວຢ່າງນີ້ໃຊ້ສ່ວນຕິດຕໍ່ ASGI ຂອງ Granian ໂດຍບໍ່ມີການຮອງຮັບ lifespan ຫຼື WebSocket, ເນື່ອງຈາກປະຈຸບັນ Weblate ໃຫ້ບໍລິການຜ່ານ HTTP ເທົ່ານັ້ນ. ມິດເດິລແວ (middleware) ຂອງ Weblate ຮອງຮັບການຕິດຕັ້ງທັງສອງແບບ ແລະ ໃຊ້ຕົວປັບຕໍ່ທີ່ທົນທານຕໍ່ເທຣດ (thread-sensitive) ໃນສ່ວນທີ່ຍັງຕ້ອງອາໄສ Django APIs ແບບຊິງໂຄຣນັສ (synchronous). ການກວດສອບສະຖານະ (health check) ແມ່ນເປັນແບບອະຊິງໂຄຣນັສ, ແຕ່ສ່ວນສະແດງຜົນສ່ວນໃຫຍ່ຂອງ Weblate ຍັງຄົງເປັນແບບຊິງໂຄຣນັສ, ແລະ ວຽກທີ່ໃຊ້ CPU ສູງ ຫຼື ວຽກທີ່ເຮັດວຽກດົນ ຄວນຖືກຈັດການໂດຍ ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery.

WSGI ຍັງຄົງເປັນຮູບແບບການຕິດຕັ້ງເລີ່ມຕົ້ນ. Docker images ສາມາດເລືອກໃຊ້ ASGI ໄດ້ໂດຍການຕັ້ງຄ່າ WEBLATE_ASGI ເປັນ 1. ໃຫ້ປັບຈຳນວນ worker ແລະ backpressure ໃຫ້ເໝາະສົມກັບ ໜ່ວຍຄວາມຈຳ, ຄໍຂອງ CPU, ແລະ ຂີດຈຳກັດການເຊື່ອມຕໍ່ຖານຂໍ້ມູນທີ່ມີຢູ່.

See also

ການຕັ້ງຄ່າຕົວຢ່າງເພື່ອເລີ່ມຕົ້ນ Granian
https://github.com/emmett-framework/granian
How to deploy with ASGI

ການຕັ້ງຄ່າຕົວຢ່າງເພື່ອເລີ່ມຕົ້ນ Gunicorn¶

Gunicorn ຕ້ອງຖືກຕິດຕັ້ງແຍກຕ່າງຫາກ:

uv pip install gunicorn

ເມື່ອຕິດຕັ້ງ Gunicorn ແລ້ວ, ເຈົ້າສາມາດແລ່ນມັນໄດ້. ປົກກະຕິແລ້ວຈະເຮັດໃນລະດັບລະບົບ. ຕົວຢ່າງຕໍ່ໄປນີ້ສະແດງການເລີ່ມຕົ້ນຜ່ານ systemd:

/etc/systemd/system/gunicorn.socket¶

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

/etc/systemd/system/gunicorn.service¶

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
    --preload \
    --timeout 3600 \
    --graceful-timeout 3600 \
    --worker-class=gthread \
    --workers=2 \
    --threads=16 \
    --bind unix:/run/gunicorn.sock \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target

See also

How to use Django with Gunicorn

ການແລ່ນ Weblate ພາຍໃຕ້ Path¶

ແນະນຳໃຫ້ໃຊ້ Prefork MPM ເມື່ອໃຊ້ WSGI ກັບ Weblate.

ຕົວຢ່າງການຕັ້ງຄ່າ Apache ເພື່ອໃຫ້ບໍລິການ Weblate ພາຍໃຕ້ /weblate. ໃຊ້ mod_wsgi ເຊັ່ນເຄີຍ (weblate/examples/apache-path.conf ໃນ Source tree):

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /weblate/static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        Require all granted
    </Directory>

    # Path to your Weblate Python environment
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

ນອກຈາກນີ້, ເຈົ້າຈະຕ້ອງປັບແຕ່ງ weblate/settings.py:

URL_PREFIX = "/weblate"

ວຽກງານເບື້ອງຫຼັງໂດຍໃຊ້ Celery¶

Weblate ໃຊ້ Celery ເພື່ອດຳເນີນການວຽກງານປົກກະຕິ ແລະ ວຽກງານເບື້ອງຫຼັງ. ເຈົ້າຈຳເປັນຕ້ອງແລ່ນບໍລິການ Celery ເພື່ອເຮັດໜ້າທີ່ນີ້. ຕົວຢ່າງ, ມັນຮັບຜິດຊອບໃນການຈັດການການດຳເນີນງານດັ່ງນີ້ (ລາຍການນີ້ຍັງບໍ່ຄົບຖ້ວນ):

ການຮັບ Webhooks ຈາກບໍລິການພາຍນອກ (ເບິ່ງ ຮຸກການແຈ້ງເຕືອນ).
ການແລ່ນວຽກງານບຳລຸງຮັກສາເປັນປົກກະຕິ ເຊັ່ນ: ການສຳຮອງຂໍ້ມູນ, ການທຳຄວາມສະອາດ, Add-ons ປະຈຳວັນ, ຫຼື ການອັບເດດ (ເບິ່ງ ການສຳຮອງຂໍ້ມູນ ແລະການຍ້າຍ Weblate, BACKGROUND_TASKS, ສ່ວນເສີມ).
ການແລ່ນ ການແປອັດຕະໂນມັດ.
ການສົ່ງການແຈ້ງເຕືອນແບບ Digest.
ການຍ້າຍການດຳເນີນງານທີ່ໃຊ້ຊັບພະຍາກອນສູງອອກຈາກ WSGI process.
ການຄອມມິດການປ່ຽນແປງທີ່ຄ້າງໄວ້ (ເບິ່ງ Lazy commits).

ການຕັ້ງຄ່າທົ່ວໄປທີ່ໃຊ້ Valkey ຫຼື Redis ເປັນ Backend ມີລັກສະນະດັ່ງນີ້:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

See also

ການຕັ້ງຄ່າ Redis broker ໃນ Celery

ເຈົ້າຄວນເລີ່ມຕົ້ນ Celery worker ເພື່ອປະມວນຜົນວຽກງານຕ່າງໆ ແລະ ເລີ່ມຕົ້ນວຽກງານທີ່ຕັ້ງເວລາໄວ້. ສຳລັບການ Debug ຫຼື ພັດທະນາ, ສິ່ງນີ້ສາມາດເຮັດໄດ້ໂດຍກົງຜ່ານ Command-line:

celery --app=weblate.utils worker --beat \
    --queues=celery,notify,memory,translate,backup \
    --prefetch-multiplier=1

Running all queues in one prefork worker shares the initial application memory between its child processes while retaining parallel task execution. Celery determines the concurrency from the number of available CPUs by default; use --concurrency to adjust it for your workload and available memory.

ເພື່ອຫຼຸດຜ່ອນການໃຊ້ຄວາມຈຳໃນຕອນເລີ່ມຕົ້ນ, Celery workers ຈະບໍ່ເຮັດການກວດສອບລະບົບ Django ຊ້ຳ. ຄອນເທນເນີ Weblate ຈະລັນຄຳສັ່ງ weblate check --deploy ທີ່ຄອບຄຸມກວ່າໂດຍອັດຕະໂນມັດ ໃນລະຫວ່າງການເລີ່ມຕົ້ນຄອນເທນເນີ. ສຳລັບວິທີການຕິດຕັ້ງອື່ນໆ, ໃຫ້ລັນຄຳສັ່ງຫຼັງຈາກການຕິດຕັ້ງ, ການອັບເກຣດ ຫຼື ການປ່ຽນແປງການຕັ້ງຄ່າ. ການກວດສອບຍັງມີໃຫ້ໃນ ສ່ວນຕິດຕໍ່ການຈັດການ.

Note

Celery process ຕ້ອງຖືກແລ່ນພາຍໃຕ້ User ດຽວກັນກັບ WSGI process, ຖ້າບໍ່ດັ່ງນັ້ນໄຟລ໌ໃນ DATA_DIR ຈະຖືກຈັດເກັບດ້ວຍ Ownership ທີ່ປົນເປກັນ, ເຮັດໃຫ້ເກີດບັນຫາໃນລະຫວ່າງການໃຊ້ງານ.

ເບິ່ງເພີ່ມເຕີມ ສິດທິລະບົບໄຟລ໌ ແລະ ການແລ່ນເຊີບເວີ.

ການດຳເນີນການ Celery tasks ໃນ WSGI ໂດຍໃຊ້ Eager mode¶

Note

ສິ່ງນີ້ຈະສົ່ງຜົນກະທົບຢ່າງຮຸນແຮງຕໍ່ປະສິດທິພາບຂອງເວັບອິນເຕີເຟດ, ແລະ ຈະເຮັດໃຫ້ຟີເຈີທີ່ຂຶ້ນກັບການກະຕຸ້ນ (Trigger) ເປັນປົກກະຕິໃຊ້ງານບໍ່ໄດ້ (ຕົວຢ່າງ: ການຄອມມິດການປ່ຽນແປງ, ການແຈ້ງເຕືອນແບບ Digest, ຫຼື ການສຳຮອງຂໍ້ມູນ).

ສຳລັບການພັດທະນາ, ເຈົ້າອາດຈະຢາກໃຊ້ Eager configuration, ເຊິ່ງຈະປະມວນຜົນວຽກງານທັງໝົດໃນທີ່ດຽວ:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

ການແລ່ນ Celery ເປັນ System service¶

ສ່ວນໃຫຍ່ແລ້ວເຈົ້າຈະຢາກແລ່ນ Celery ເປັນ Daemon ເຊິ່ງມີອະທິບາຍໄວ້ໃນ Daemonization. ສຳລັບການຕັ້ງຄ່າ Linux ທົ່ວໄປໂດຍໃຊ້ systemd, ໃຫ້ປັບໃຊ້ໄຟລ໌ຕົວຢ່າງທີ່ລະບຸຢູ່ລຸ່ມນີ້. ໄຟລ໌ຕົວຢ່າງເຫຼົ່ານີ້ຖືກເບິ່ງແຍງຢູ່ໃນ Weblate source tree ພາຍໃຕ້ weblate/examples/; Python wheels ບໍ່ໄດ້ຕິດຕັ້ງໄຟລ໌ Deployment samples ເຫຼົ່ານີ້.

Systemd unit ທີ່ຕ້ອງວາງໄວ້ທີ່ /etc/systemd/system/celery-weblate.service:

[Unit]
Description=Celery Service (Weblate)
After=network.target

[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
  --pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

[Install]
WantedBy=multi-user.target

ການຕັ້ງຄ່າ Environment ທີ່ຕ້ອງວາງໄວ້ທີ່ /etc/default/celery-weblate:

# Name of nodes to start
CELERYD_NODES="combined"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"

# Extra command-line arguments to the worker. Celery determines concurrency
# from the number of available CPUs by default. You might need to customize it
# depending on the available resources and Weblate usage. Increase concurrency
# if you get weblate.E019 error, decrease it on a low-resource system.
# Command-line values override corresponding Celery settings in settings.py.
CELERYD_OPTS="--beat:combined --queues:combined=celery,notify,memory,translate,backup --prefetch-multiplier:combined=1"

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

ການຕັ້ງຄ່າເພີ່ມເຕີມເພື່ອ Rotate Celery logs ໂດຍໃຊ້ logrotate ທີ່ຕ້ອງວາງໄວ້ທີ່ /etc/logrotate.d/celery:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

ວຽກງານເປັນໄລຍະໂດຍໃຊ້ Celery beat¶

Weblate ມາພ້ອມກັບການຕັ້ງຄ່າ Built-in ສຳລັບ Scheduled tasks. ຕາຕະລາງວຽກງານຈະຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນ ແລະ ວຽກງານຈະຖືກດຳເນີນການໂດຍ Celery beat daemon.

Hint

ເຈົ້າສາມາດກຳນົດວຽກງານເພີ່ມເຕີມໄດ້ໃນ settings.py, ຕົວຢ່າງເບິ່ງ Lazy commits.

ການຕິດຕາມສະຖານະ Celery¶

ເຈົ້າສາມາດເບິ່ງຄວາມຍາວປັດຈຸບັນຂອງ Celery task queues ໃນ ອິນເຕີເຟດການຈັດການ ຫຼື ໃຊ້ celery_queues ເທິງ Command-line. ໃນກໍລະນີທີ່ຄິວ (Queue) ຍາວເກີນໄປ, ເຈົ້າຈະໄດ້ຮັບຂໍ້ຜິດພາດການຕັ້ງຄ່າໃນອິນເຕີເຟດຜູ້ເບິ່ງແຍງລະບົບ.

Warning

ໂດຍຄ່າເລີ່ມຕົ້ນ, ຂໍ້ຜິດພາດຂອງ Celery ຈະຖືກບັນທຶກໄວ້ໃນ Celery log ເທົ່ານັ້ນ ແລະ ບໍ່ເຫັນໄດ້ໂດຍຜູ້ໃຊ້. ໃນກໍລະນີທີ່ເຈົ້າຕ້ອງການພາບລວມຂອງຄວາມຜິດພາດດັ່ງກ່າວ, ແນະນຳໃຫ້ຕັ້ງຄ່າ ການເກັບລາຍງານຂໍ້ຜິດພາດ ແລະ ການຕິດຕາມປະສິດທິພາບ.

See also

ການຕັ້ງຄ່າ Celery ແບບ Single-process¶

ໃນກໍລະນີທີ່ເຈົ້າມີໜ່ວຍຄວາມຈຳຈຳກັດຫຼາຍ, ເຈົ້າອາດຈະຢາກຫຼຸດຈຳນວນ Weblate processes. Celery tasks ທັງໝົດສາມາດດຳເນີນການໄດ້ໃນ Process ດຽວໂດຍໃຊ້:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo

An installation using Docker can be configured to use a single-process Celery setup by setting CELERY_WORKER_MODE=single. See CELERY_WORKER_MODE.

Warning

ສິ່ງນີ້ຈະສົ່ງຜົນກະທົບຕໍ່ປະສິດທິພາບຂອງ Weblate ຢ່າງເຫັນໄດ້ຊັດ.

ການຕິດຕາມ Weblate¶

Weblate ມີ URL /healthz/ ໄວ້ໃຫ້ໃຊ້ສຳລັບການກວດສອບ Health check ແບບງ່າຍໆ, ຕົວຢ່າງໂດຍໃຊ້ Kubernetes. Docker container ມີ Built-in health check ທີ່ໃຊ້ URL ນີ້.

ສຳລັບການຕິດຕາມຕົວຊີ້ວັດ (metrics) ຂອງ Weblate ເຈົ້າສາມາດໃຊ້ API endpoint GET /api/metrics/. ເຄື່ອງມືຕິດຕາມທີ່ລັນຢູ່ໃນເຄື່ອງ (locally) ສາມາດດຶງຂໍ້ມູນຕົວຊີ້ວັດດຽວກັນໄດ້ໂດຍໃຊ້ຄຳສັ່ງ metrics.

See also

ການເກັບລາຍງານຂໍ້ຜິດພາດ ແລະ ການຕິດຕາມປະສິດທິພາບ¶

Weblate, ເຊັ່ນດຽວກັບຊອບແວອື່ນໆ, ສາມາດເກີດຂໍ້ຜິດພາດໄດ້. ເພື່ອເກັບສະຖານະຂໍ້ຜິດພາດທີ່ເປັນປະໂຫຍດ, ພວກເຮົາແນະນຳໃຫ້ໃຊ້ບໍລິການຈາກພາກສ່ວນທີສາມເພື່ອເກັບຂໍ້ມູນດັ່ງກ່າວ. ນີ້ຈະເປັນປະໂຫຍດໂດຍສະເພາະໃນກໍລະນີທີ່ Celery tasks ລົ້ມເຫຼວ, ເຊິ່ງປົກກະຕິແລ້ວມັນຈະລາຍງານພຽງແຕ່ໃນ Log ແລະ ເຈົ້າຈະບໍ່ໄດ້ຮັບການແຈ້ງເຕືອນ. Weblate ຮອງຮັບບໍລິການຕໍ່ໄປນີ້:

ອີເມວ¶

ການຕັ້ງຄ່າເລີ່ມຕົ້ນຂອງ Weblate ຈະເຮັດໃຫ້ Django ສົ່ງອີເມວເມື່ອເກີດຂໍ້ຜິດພາດໃນເຊີບເວີຜ່ານ django.utils.log.AdminEmailHandler. ນີ້ເປັນການຕັ້ງຄ່າທີ່ງ່າຍທີ່ສຸດ, ແຕ່ເຈົ້າຄວນພິຈາລະນາທາງເລືອກອື່ນຍ້ອນເຫດຜົນດ້ານຄວາມເປັນສ່ວນຕົວ, ເນື່ອງຈາກອີເມວຂໍ້ຜິດພາດອາດມີຂໍ້ມູນທີ່ລະອຽດອ່ອນ. ເຈົ້າສາມາດອ່ານເພີ່ມເຕີມໃນ Security implications.

ເພື່ອປິດພຶດຕິກຳນີ້, ໃຫ້ເອົາ mail_admins ອອກຈາກ LOGGING ໃນການຕັ້ງຄ່າ Weblate, ຫຼື ປິດ WEBLATE_ADMIN_NOTIFY_ERROR ໃນ Docker environment.

Sentry¶

Weblate ມີການຮອງຮັບ Sentry ໃນຕົວ. ເພື່ອໃຊ້ງານ, ພຽງແຕ່ຕັ້ງຄ່າ SENTRY_DSN ໃນໄຟລ໌ settings.py:

SENTRY_DSN = "https://id@your.sentry.example.com/"

Sentry ຍັງສາມາດໃຊ້ເພື່ອຕິດຕາມປະສິດທິພາບຂອງ Weblate ໂດຍການເກັບ Traces ແລະ Profiles ສຳລັບເປີເຊັນທີ່ກຳນົດໄວ້ຂອງການດຳເນີນງານ. ສິ່ງນີ້ສາມາດຕັ້ງຄ່າໄດ້ໂດຍໃຊ້ SENTRY_TRACES_SAMPLE_RATE ແລະ SENTRY_PROFILES_SAMPLE_RATE.

See also

Google Cloud Error Reporting¶

Weblate ສາມາດລາຍງານຂໍ້ຜິດພາດຂອງເຊີບເວີທີ່ຈັດການໄດ້ໄປຍັງ Google Cloud Error Reporting. ໃຫ້ຕິດຕັ້ງ Weblate ດ້ວຍ google-errors extra ແລະ ຕັ້ງຄ່າ GOOGLE_CLOUD_ERROR_REPORTING ໃນ settings.py:

GOOGLE_CLOUD_ERROR_REPORTING = {
    "project": "your-google-cloud-project",
}

Weblate ຈະລາຍງານຂໍ້ຜິດພາດພາຍໃຕ້ບໍລິການ weblate ໂດຍອັດຕະໂນມັດ ແລະ ໃຊ້ເວີຊັ່ນ Weblate ຫຼື Git revision ປັດຈຸບັນເປັນເວີຊັ່ນທີ່ລາຍງານ. ຄ່າເຫຼົ່ານີ້ສາມາດຖືກ Override ໄດ້ໂດຍການຕັ້ງຄ່າ service ຫຼື version ໃນ GOOGLE_CLOUD_ERROR_REPORTING.

OpenTelemetry¶

Weblate ສາມາດ Export backend traces ໂດຍໃຊ້ OpenTelemetry. ມັນໃຊ້ OTLP over HTTP ແລະ ສາມາດສົ່ງ Traces ໄປຍັງ OpenTelemetry Collector ຫຼື Vendor endpoint ທີ່ຮອງຮັບ.

OPENTELEMETRY_ENABLED = True
OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT = "https://collector.example.com/v1/traces"
OPENTELEMETRY_TRACES_SAMPLE_RATE = 0.1

Integration ດັ່ງກ່າວຈະຕິດຕາມ Django requests, Celery tasks, Redis, outgoing HTTP requests, database calls, ແລະ Weblate-specific spans. ໃຫ້ຕັ້ງຄ່າໂດຍໃຊ້ OPENTELEMETRY_ENABLED, OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT, ແລະ OPENTELEMETRY_TRACES_SAMPLE_RATE.

Rollbar¶

Weblate ມີການຮອງຮັບ Rollbar ໃນຕົວ. ເພື່ອໃຊ້ງານ, ພຽງແຕ່ປະຕິບັດຕາມຄຳແນະນຳສຳລັບ Rollbar notifier ສຳລັບ Python.

ໂດຍຫຍໍ້, ເຈົ້າຈຳເປັນຕ້ອງປັບແຕ່ງ settings.py:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # … other middleware classes …
    "rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]

# Configure client access
ROLLBAR = {
    "access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

ທຸກຢ່າງຖືກລວມເຂົ້າອັດຕະໂນມັດ, ດຽວນີ້ເຈົ້າຈະເກັບຂໍ້ຜິດພາດທັງຝັ່ງເຊີບເວີ ແລະ Client.

Note

Error logging ຍັງລວມເຖິງ Exception ທີ່ຖືກຈັດການຢ່າງຖືກຕ້ອງ ແຕ່ອາດຊີ້ໃຫ້ເຫັນເຖິງບັນຫາ - ເຊັ່ນ: ການ Parse ໄຟລ໌ທີ່ອັບໂຫຼດຜິດພາດ.

ການຈັດການ Log ແບບ Graylog¶

Added in version 5.9.

Weblate ສາມາດຖືກຕັ້ງຄ່າໃຫ້ Log ໂດຍໃຊ້ໂປຣໂຕຄໍ GELF TCP. ສິ່ງນີ້ຖືກພັດທະນາເພື່ອການເຊື່ອມຕໍ່ກັບ Graylog, ແຕ່ສາມາດໃຊ້ກັບ Platform ການ Log ໃດກໍໄດ້ທີ່ຮອງຮັບ.

Boilerplate ການຕັ້ງຄ່າໄດ້ລວມຢູ່ໃນ ຕົວຢ່າງການຕັ້ງຄ່າ, ສຳລັບ Docker ສິ່ງນີ້ສາມາດຕັ້ງຄ່າໄດ້ໂດຍໃຊ້ WEBLATE_LOG_GELF_HOST.

ການຍ້າຍ Weblate ໄປຍັງເຊີບເວີອື່ນ¶

ການຍ້າຍ Weblate ໄປຍັງເຊີບເວີອື່ນຄວນຈະງ່າຍຫຼາຍ, ຢ່າງໃດກໍຕາມມັນຈັດເກັບຂໍ້ມູນໄວ້ໃນບາງຕຳແໜ່ງທີ່ເຈົ້າຄວນຍ້າຍຢ່າງລະມັດລະວັງ. ວິທີທີ່ດີທີ່ສຸດແມ່ນການຢຸດ Weblate ກ່ອນການຍ້າຍ.

ການຍ້າຍຖານຂໍ້ມູນ¶

ວິທີທີ່ກົງໄປກົງມາທີ່ສຸດແມ່ນການໃຊ້ເຄື່ອງມືພື້ນຖານຂອງຖານຂໍ້ມູນ, ເນື່ອງຈາກປົກກະຕິພວກມັນມີປະສິດທິພາບຫຼາຍທີ່ສຸດ (ຕົວຢ່າງ: pg_dump). ຫຼື ເຈົ້າສາມາດໃຊ້ Replication ຖ້າຖານຂໍ້ມູນຂອງທ່ານຮອງຮັບ.

See also

ການຍ້າຍລະຫວ່າງຖານຂໍ້ມູນມີອະທິບາຍໄວ້ໃນ ການຍ້າຍຈາກຖານຂໍ້ມູນອື່ນໄປຫາ PostgreSQL.

ການຍ້າຍ VCS repositories¶

VCS repositories ທີ່ເກັບໄວ້ພາຍໃຕ້ DATA_DIR ຈຳເປັນຕ້ອງຖືກຍ້າຍນຳ. ເຈົ້າສາມາດກັອບປີ້ພວກມັນໄດ້ງ່າຍໆ ຫຼື ໃຊ້ rsync ເພື່ອຍ້າຍໃຫ້ມີປະສິດທິພາບຍິ່ງຂຶ້ນ.

ໝາຍເຫດອື່ນໆ¶

ຢ່າລືມຍ້າຍບໍລິການອື່ນໆທີ່ Weblate ອາດຈະໄດ້ໃຊ້ງານ ເຊັ່ນ: Valkey, Redis, Cron jobs ຫຼື Custom authentication backends.