ຄຳຖາມທີ່ພົບເລື້ອຍ (FAQ)

ການຕັ້ງຄ່າ

ຈະສ້າງຂັ້ນຕອນການເຮັດວຽກແບບອັດຕະໂນມັດໄດ້ແນວໃດ?

Weblate ສາມາດຈັດການທຸກຢ່າງກ່ຽວກັບການແປໃຫ້ເຈົ້າແບບກິ່ງອັດຕະໂນມັດ. ຖ້າເຈົ້າໃຫ້ສິດການ push ໃຫ້ກັບ repository ຂອງເຈົ້າ, ການແປສາມາດເກີດຂຶ້ນໄດ້ໂດຍບໍ່ຕ້ອງມີການໂຕ້ຕອບ, ເວັ້ນເສຍແຕ່ວ່າຈະມີບັນຫາ merge conflict.

  1. ຕັ້ງຄ່າ Git repository ຂອງເຈົ້າເພື່ອບອກ Weblate ເມື່ອມີການປ່ຽນແປງໃດໆ, ເບິ່ງ ຮຸກການແຈ້ງເຕືອນ ສຳລັບຂໍ້ມູນກ່ຽວກັບວິທີການເຮັດ.

  2. ຕັ້ງຄ່າ push URL ທີ່ ການຕັ້ງຄ່າ Component ຂອງເຈົ້າໃນ Weblate, ສິ່ງນີ້ອະນຸຍາດໃຫ້ Weblate push ການປ່ຽນແປງໄປຍັງ repository ຂອງເຈົ້າ.

  3. ເປີດໃຊ້ Push ເມື່ອບັນທຶກການປ່ຽນແປງ (Commit) ທີ່ ການຕັ້ງຄ່າ Component ຂອງເຈົ້າໃນ Weblate, ສິ່ງນີ້ຈະເຮັດໃຫ້ Weblate push ການປ່ຽນແປງໄປຍັງ repository ຂອງເຈົ້າທຸກຄັ້ງທີ່ມັນເກີດຂຶ້ນໃນ Weblate.

ຈະເຂົ້າເຖິງ repository ຜ່ານ SSH ໄດ້ແນວໃດ?

ກະລຸນາເບິ່ງ ການເຂົ້າເຖິງຄັງເກັບ (repositories) ສຳລັບຂໍ້ມູນກ່ຽວກັບການຕັ້ງຄ່າ SSH keys.

ຈະແກ້ໄຂ merge conflict ໃນການແປໄດ້ແນວໃດ?

Merge conflicts ເກີດຂຶ້ນເປັນບາງຄັ້ງຄາວເມື່ອໄຟລ໌ການແປຖືກປ່ຽນແປງທັງໃນ Weblate ແລະ upstream repository ພ້ອມກັນ. ໂດຍທົ່ວໄປເຈົ້າສາມາດຫຼີກລ່ຽງສິ່ງນີ້ໄດ້ໂດຍການ merge ການແປຂອງ Weblate ກ່ອນທີ່ຈະເຮັດການປ່ຽນແປງໃນໄຟລ໌ການແປ (ຕົວຢ່າງ: ກ່ອນ run msgmerge). ພຽງແຕ່ບອກ Weblate ໃຫ້ commit ການແປທີ່ຍັງຄ້າງທັງໝົດ (ເຈົ້າສາມາດເຮັດໄດ້ໃນ Repository maintenance ໃນເມນູ Operations) ແລະ merge repository (ຖ້າ automatic push ບໍ່ໄດ້ຖືກເປີດ).

ຖ້າເຈົ້າພົບ merge conflict ແລ້ວ, ວິທີທີ່ງ່າຍທີ່ສຸດໃນການແກ້ໄຂ conflicts ທັງໝົດໃນເຄື່ອງຂອງເຈົ້າ ແມ່ນການເພີ່ມ Weblate ເປັນ remote repository, merge ມັນເຂົ້າໃນ upstream ແລະ ແກ້ໄຂ conflicts. ເມື່ອເຈົ້າ push ການປ່ຽນແປງກັບຄືນ, Weblate ຈະສາມາດໃຊ້ເວີຊັນທີ່ merge ແລ້ວໂດຍບໍ່ຕ້ອງມີການດຳເນີນການພິເສດໃດໆ.

Note

ຖ້າເຈົ້າແກ້ໄຂ conflict ໃນ pull request, ໃຫ້ merge ມັນດ້ວຍ regular merge commit. ຢ່າໃຊ້ squash merge. Squash merge ຈະສ້າງ commit ໃໝ່ ແທນທີ່ຈະຮັກສາ Weblate commits ໄວ້, ດັ່ງນັ້ນ Weblate ອາດຈະບໍ່ຮັບຮູ້ວ່າ local commits ຂອງມັນໄດ້ຖືກລວມຢູ່ໃນ upstream ແລ້ວ ແລະ ອາດຕ້ອງໄດ້ reset repository ເພື່ອກູ້ຄືນ.

Note

Weblate ໃຊ້ shallow clones ໂດຍຄ່າເລີ່ມຕົ້ນເພື່ອຫຼຸດເວລາ cloning ແລະ ການໃຊ້ງານດິດ. ດ້ວຍເຫດນີ້, ຂັ້ນຕອນການເຮັດວຽກຂ້າງລຸ່ມນີ້ຈະເຮັດວຽກໄດ້ດີທີ່ສຸດເມື່ອເຈົ້າເລີ່ມຕົ້ນຈາກ checkout ທີ່ທັນສະໄໝຂອງ upstream repository. ຖ້າເຈົ້າ clone ໂດຍກົງຈາກ exported Weblate repository, ຫຼື ຖ້າ upstream checkout ຂອງເຈົ້າຂາດ commits ລ່າສຸດ, git remote update weblate ອາດຈະລົ້ມເຫຼວດ້ວຍ error ເຊັ່ນ warning: no common commits, bad revision, ຫຼື ວັດຖຸທີ່ຂາດຫາຍໄປ. ສິ່ງນີ້ບໍ່ໄດ້ໝາຍຄວາມວ່າ Weblate ແລະ upstream repository ມີການປ່ຽນແປງທີ່ຂັດກັນສະເໝີໄປ. ຜູ້ດູແລລະບົບທີ່ຕ້ອງການເຮັດໃຫ້ຂັ້ນຕອນການເຮັດວຽກນີ້ເຊື່ອຖືໄດ້ຫຼາຍຂຶ້ນ ສາມາດປັບ VCS_CLONE_DEPTH.

Note

ຂຶ້ນກັບການຕັ້ງຄ່າຂອງເຈົ້າ, ການເຂົ້າເຖິງ Weblate repository ອາດຕ້ອງມີການພິສູດຕົວຕົນ (authentication). ເມື່ອໃຊ້ built-in Git exporter ໃນ Weblate, ເຈົ້າຈະພິສູດຕົວຕົນດ້ວຍຊື່ຜູ້ໃຊ້ ແລະ API key ຂອງເຈົ້າ.

Note

Weblate serves the Git repository itself, but it does not serve Git LFS objects. See Git LFS for supported behavior. Clone repositories using Git LFS from the upstream repository and add Weblate as another remote. If you only need Git-tracked files, you can clone from Weblate with GIT_LFS_SKIP_SMUDGE=1 to skip downloading Git LFS objects.

ຂັ້ນຕອນການເຮັດວຽກມັກຈະເປັນແບບນີ້ເມື່ອເຈົ້າເລີ່ມຕົ້ນຈາກ checkout ທີ່ທັນສະໄໝຂອງ upstream repository:

# Open an existing up-to-date checkout of the upstream repository or perform
# a fresh one:
git clone UPSTREAM_REPOSITORY_URL
cd REPO
# Commit all pending changes in Weblate, you can do this in the UI as well:
wlc commit
# Lock the translation in Weblate, again this can be done in the UI as well:
wlc lock
# Add Weblate as remote:
git remote add weblate https://hosted.weblate.org/git/project/component/
# You might need to include credentials in some cases:
git remote add weblate https://username:APIKEY@hosted.weblate.org/git/project/component/

# Update weblate remote:
git remote update weblate

# Merge Weblate changes:
git merge weblate/main

# Resolve conflicts:
edit …
git add …
…
git commit

# Rebase changes (if Weblate is configured to do rebases)
git rebase origin/main

# Push changes to upstream repository, Weblate will fetch merge from there:
git push

# Open Weblate for translation:
wlc unlock

ຖ້າເຈົ້າໃຊ້ຫຼາຍ branches ໃນ Weblate, ເຈົ້າສາມາດເຮັດແບບດຽວກັນກັບພວກມັນທັງໝົດ:

# Add and update Weblate remotes
git remote add weblate-one https://hosted.weblate.org/git/project/one/
git remote add weblate-second https://hosted.weblate.org/git/project/second/
git remote update weblate-one weblate-second

# Merge QA_4_7 branch:
git checkout QA_4_7
git merge weblate-one/QA_4_7
... # Resolve conflicts
git commit

# Merge main branch:
git checkout main
git merge weblates-second/main
... # Resolve conflicts
git commit

# Push changes to the upstream repository, Weblate will fetch the merge from there:
git push

ໃນກໍລະນີຂອງໄຟລ໌ gettext PO, ມີວິທີການ merge conflicts ແບບກິ່ງອັດຕະໂນມັດ:

Fetch ແລະ ຮັກສາ local clone ຂອງ Weblate Git repository ໄວ້. ນອກຈາກນີ້ ໃຫ້ເອົາ local clone ທີສອງທີ່ສົດໃໝ່ຂອງ upstream Git repository (ເຊັ່ນ: ເຈົ້າຕ້ອງການ 2 ສຳເນົາຂອງ upstream Git repository: ສຳເນົາທີ່ສົມບູນ ແລະ ສຳເນົາທີ່ກຳລັງເຮັດວຽກ):

# Add remote:
git remote add weblate /path/to/weblate/snapshot/

# Update Weblate remote:
git remote update weblate

# Merge Weblate changes:
git merge weblate/main

# Resolve conflicts in the PO files:
for PO in `find . -name '*.po'` ; do
    msgcat --use-first /path/to/weblate/snapshot/$PO\
               /path/to/upstream/snapshot/$PO -o $PO.merge
    msgmerge --previous --lang=${PO%.po} $PO.merge domain.pot -o $PO
    rm $PO.merge
    git add $PO
done
git commit

# Push changes to the upstream repository, Weblate will fetch merge from there:
git push

ຂ້ອຍຈະແປຫຼາຍ branches ພ້ອມກັນໄດ້ແນວໃດ?

Weblate ຮອງຮັບການ push ການປ່ຽນແປງການແປພາຍໃນ ການຕັ້ງຄ່າໂຄງການ ດຽວ. ສຳລັບທຸກໆ ການຕັ້ງຄ່າ Component ທີ່ເປີດໃຊ້ສິ່ງນີ້ (ພຶດຕິກຳເລີ່ມຕົ້ນ), ການປ່ຽນແປງທີ່ເຮັດຈະຖືກກະຈາຍໄປສູ່ອົງປະກອບອື່ນໂດຍອັດຕະໂນມັດ. ວິທີນີ້ການແປຈະຖືກຮັກສາໃຫ້ຊິ້ງກັນ ເຖິງແມ່ນວ່າ branches ຈະແຕກຕ່າງກັນຫຼາຍແລ້ວ ແລະ ມັນບໍ່ສາມາດ merge ການປ່ຽນແປງການແປລະຫວ່າງພວກມັນໄດ້ງ່າຍໆ.

ເມື່ອເຈົ້າ merge ການປ່ຽນແປງຈາກ Weblate, ເຈົ້າອາດຕ້ອງ merge branches ເຫຼົ່ານີ້ (ຂຶ້ນກັບຂັ້ນຕອນການພັດທະນາຂອງເຈົ້າ) ໂດຍຍົກເລີກຄວາມແຕກຕ່າງ:

git merge -s ours origin/maintenance

ຈະແປໂຄງການ multi-platform ໄດ້ແນວໃດ?

Weblate ຮອງຮັບຮູບແບບໄຟລ໌ທີ່ຫຼາກຫຼາຍ (ເບິ່ງ ຮູບແບບໄຟລ໌ການແປພາສາ) ແລະ ວິທີທີ່ງ່າຍທີ່ສຸດຄືການໃຊ້ຮູບແບບ native ສຳລັບແຕ່ລະແພລັດຟອມ.

ເມື່ອເຈົ້າເພີ່ມໄຟລ໌ການແປທຸກແພລັດຟອມເປັນ components ໃນໂຄງການດຽວແລ້ວ (ເບິ່ງ ການເພີ່ມໂຄງການແປ ແລະ ອົງປະກອບ), ເຈົ້າສາມາດນຳໃຊ້ຄຸນສົມບັດການກະຈາຍການແປ (translation propagation) (ເປີດໃຊ້ໂດຍເລີ່ມຕົ້ນ, ແລະ ສາມາດປິດໄດ້ໃນ ການຕັ້ງຄ່າ Component) ເພື່ອແປຂໍ້ຄວາມສຳລັບທຸກແພລັດຟອມພ້ອມກັນ.

ຈະສົ່ງອອກ Git repository ທີ່ Weblate ໃຊ້ໄດ້ແນວໃດ?

ບໍ່ມີຫຍັງພິເສດກ່ຽວກັບ repository ນັ້ນ, ມັນຢູ່ໃນໄດເລກະທໍລີ DATA_DIR ແລະ ມີຊື່ວ່າ vcs/<project>/<component>/. ຖ້າເຈົ້າມີການເຂົ້າເຖິງ SSH ໄປຍັງເຄື່ອງນີ້, ເຈົ້າສາມາດໃຊ້ repository ໄດ້ໂດຍກົງ.

ສຳລັບການເຂົ້າເຖິງແບບບໍ່ລະບຸຕົວຕົນ, ເຈົ້າອາດຈະຕ້ອງການ run Git server ແລະ ໃຫ້ມັນໃຫ້ບໍລິການ repository ແກ່ໂລກພາຍນອກ.

ອີກທາງເລືອກໜຶ່ງ, ເຈົ້າສາມາດໃຊ້ Git exporter ພາຍໃນ Weblate ເພື່ອເຮັດໃຫ້ສິ່ງນີ້ເປັນອັດຕະໂນມັດ.

ມີຕົວເລືອກໃດແດ່ສຳລັບການ push ການປ່ຽນແປງກັບຄືນ upstream?

ສິ່ງນີ້ຂຶ້ນກັບການຕັ້ງຄ່າຂອງເຈົ້າຫຼາຍ, Weblate ມີຄວາມຍືດຫຍຸ່ນຫຼາຍໃນພື້ນທີ່ນີ້. ນີ້ຄືຕົວຢ່າງຂອງຂັ້ນຕອນການເຮັດວຽກບາງຢ່າງທີ່ໃຊ້ກັບ Weblate:

  • Weblate ເຮັດການ push ແລະ merge ການປ່ຽນແປງໂດຍອັດຕະໂນມັດ (ເບິ່ງ ຈະສ້າງຂັ້ນຕອນການເຮັດວຽກແບບອັດຕະໂນມັດໄດ້ແນວໃດ?).

  • ເຈົ້າບອກ Weblate ໃຫ້ push ດ້ວຍຕົນເອງ (ມັນຕ້ອງການສິດ push ໄປຍັງ upstream repository).

  • ບາງຄົນ merge ການປ່ຽນແປງຈາກ Weblate git repository ເຂົ້າໃນ upstream repository ດ້ວຍຕົນເອງ.

  • ບາງຄົນຂຽນປະຫວັດທີ່ Weblate ສ້າງຂຶ້ນໃໝ່ (ຕົວຢ່າງໂດຍການກຳຈັດ merge commits), merge ການປ່ຽນແປງ, ແລະ ບອກ Weblate ໃຫ້ reset ເນື້ອຫາໃນ upstream repository.

ແນ່ນອນ ເຈົ້າມີອິດສະຫຼະໃນການປະສົມປະສານສິ່ງເຫຼົ່ານີ້ທັງໝົດຕາມທີ່ເຈົ້າຕ້ອງການ.

ຂ້ອຍຈະຈຳກັດການເຂົ້າເຖິງ Weblate ໃຫ້ມີພຽງແຕ່ການແປ, ໂດຍບໍ່ຕ້ອງເປີດເຜີຍ source code ໃຫ້ກັບມັນໄດ້ແນວໃດ?

ເຈົ້າສາມາດໃຊ້ git submodule ເພື່ອແຍກການແປອອກຈາກ source code ໃນຂະນະທີ່ຍັງຮັກສາພວກມັນໄວ້ພາຍໃຕ້ການຄວບຄຸມເວີຊັນ (version control).

  1. ສ້າງ repository ດ້ວຍໄຟລ໌ການແປຂອງເຈົ້າ.

  2. ເພີ່ມສິ່ງນີ້ເປັນ submodule ເຂົ້າໃນ code ຂອງເຈົ້າ:

    git submodule add git@example.com:project-translations.git path/to/translations
    
  3. ເຊື່ອມຕໍ່ Weblate ກັບ repository ນີ້, ມັນບໍ່ຈຳເປັນຕ້ອງເຂົ້າເຖິງ repository ທີ່ມີ source code ຂອງເຈົ້າອີກຕໍ່ໄປ.

  4. ເຈົ້າສາມາດອັບເດດ main repository ດ້ວຍການແປຈາກ Weblate ໂດຍ:

    git submodule update --remote path/to/translations
    

ກະລຸນາປຶກສາຫາລືເອກະສານ git submodule ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ.

ຂ້ອຍຈະກວດສອບໄດ້ແນວໃດວ່າ Weblate ຂອງຂ້ອຍຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ?

Weblate ລວມມີຊຸດການກວດສອບການຕັ້ງຄ່າທີ່ເຈົ້າສາມາດເຫັນໄດ້ໃນ admin interface, ພຽງແຕ່ຕິດຕາມລິ້ງ Performance report ໃນ admin interface, ຫຼື ເປີດ URL /manage/performance/ ໂດຍກົງ.

ເປັນຫຍັງ commits ທັງໝົດຈຶ່ງຖືກ commit ໂດຍ Weblate <noreply@weblate.org>?

Weblate ໃຊ້ Weblate <noreply@weblate.org> ເປັນ committer ເລີ່ມຕົ້ນສຳລັບ commits ທັງໝົດ, ເຊິ່ງຖືກກຳນົດໂດຍ DEFAULT_COMMITER_EMAIL ແລະ DEFAULT_COMMITER_NAME. ນີ້ແມ່ນຕົວລະບຸທາງເຕັກນິກທີ່ສະແດງວ່າ commit ນັ້ນຖືກປະມວນຜົນຜ່ານ Weblate.

ຢ່າງໃດກໍຕາມ, author ຂອງແຕ່ລະ commit ຈະຖືກບັນທຶກຢ່າງຖືກຕ້ອງວ່າເປັນຜູ້ໃຊ້ແຕ່ລະຄົນທີ່ເຮັດການແປ (ເມື່ອໃຊ້ Git). ນີ້ໝາຍຄວາມວ່າເຈົ້າສາມາດເຫັນໄດ້ວ່າໃຜແປຂໍ້ຄວາມໃດແທ້ໆໂດຍການກວດສອບຟີລ໌ commit author. ສິ່ງດຽວກັນນີ້ໃຊ້ກັບ Mercurial; ມີພຽງແຕ່ Subversion ເທົ່ານັ້ນທີ່ບໍ່ມີຄວາມສາມາດນີ້.

Note

ໃນ Git, ມີຄວາມແຕກຕ່າງລະຫວ່າງ committer (ຜູ້ທີ່ສ້າງ commit object) ແລະ author (ຜູ້ທີ່ເຮັດການປ່ຽນແປງ). Weblate ເຮັດໜ້າທີ່ເປັນ committer ໃນຂະນະທີ່ຮັກສາການໃຫ້ກຽດ (attribution) ຜູ້ແປແຕ່ລະຄົນໃນຖານະ author.

ສຳລັບ commits ທີ່ບໍ່ສາມາດກຳນົດ authorship ໄດ້ (ເຊັ່ນ: ການປ່ຽນແປງອັດຕະໂນມັດຈາກຄຳແນະນຳທີ່ບໍ່ລະບຸຕົວຕົນ ຫຼື ຜົນການແປດ້ວຍເຄື່ອງຈັກ), author ຈະຖືກຕັ້ງເປັນຜູ້ໃຊ້ທີ່ບໍ່ລະບຸຕົວຕົນ. ເຈົ້າສາມາດຕັ້ງຄ່າຊື່ ແລະ ອີເມວຂອງຜູ້ໃຊ້ທີ່ບໍ່ລະບຸຕົວຕົນໃນ ANONYMOUS_USER_NAME.

ຈະຍ້າຍໄຟລ໌ໃນ repository ໂດຍບໍ່ໃຫ້ປະຫວັດໃນ Weblate ຫາຍໄປໄດ້ແນວໃດ?

ເພື່ອຮັກສາປະຫວັດ, ຄວາມຄິດເຫັນ, ຫຼື screenshots ທີ່ເຊື່ອມຕໍ່ກັບຂໍ້ຄວາມຫຼັງຈາກການປ່ຽນແປງສະຖານທີ່ໄຟລ໌, ເຈົ້າຕ້ອງຮັບປະກັນວ່າຂໍ້ຄວາມເຫຼົ່ານີ້ຈະບໍ່ຖືກລຶບໃນ Weblate. ການລຶບເຫຼົ່ານີ້ສາມາດເກີດຂຶ້ນໄດ້ໃນກໍລະນີທີ່ Weblate repository ຖືກອັບເດດ, ແຕ່ການຕັ້ງຄ່າອົງປະກອບຍັງຊີ້ໄປທີ່ໄຟລ໌ເກົ່າ. ສິ່ງນີ້ເຮັດໃຫ້ Weblate ຄິດວ່າມັນຄວນລຶບການແປທັງໝົດ.

ວິທີແກ້ໄຂສຳລັບສິ່ງນີ້ຄືການປະຕິບັດການດຳເນີນການໃຫ້ສອດຄ່ອງກັບ Weblate:

  1. ລັອກອົງປະກອບທີ່ໄດ້ຮັບຜົນກະທົບໃນ Weblate.

  2. Commit ການປ່ຽນແປງທີ່ຍັງຄ້າງທັງໝົດ ແລະ merge ພວກມັນເຂົ້າໃນ upstream repository.

  3. ປິດການຮັບ webhooks ຂອງ ການຕັ້ງຄ່າໂຄງການ; ສິ່ງນີ້ປ້ອງກັນບໍ່ໃຫ້ Weblate ເຫັນການປ່ຽນແປງໃນ repository ທັນທີ.

  4. ເຮັດການປ່ຽນແປງທີ່ຈຳເປັນໃນ repo (ຕົວຢ່າງໂດຍໃຊ້ git mv), push ພວກມັນໄປຍັງ upstream repository.

  5. ປ່ຽນ ການຕັ້ງຄ່າ Component ໃຫ້ກົງກັບການຕັ້ງຄ່າໃໝ່; ເມື່ອປ່ຽນການຕັ້ງຄ່າ, Weblate ຈະ fetch repository ທີ່ອັບເດດແລ້ວ ແລະ ສັງເກດເຫັນສະຖານທີ່ທີ່ປ່ຽນໄປໃນຂະນະທີ່ຮັກສາຂໍ້ຄວາມທີ່ມີຢູ່.

  6. ປົດລັອກອົງປະກອບ ແລະ ເປີດໃຊ້ hooks ຄືນໃໝ່ໃນການຕັ້ງຄ່າໂຄງການ.

Hint

ການສຳຮອງຂໍ້ມູນລະດັບໂປຣເຈັກ ອາດເປັນປະໂຫຍດທີ່ຈະປະຕິບັດກ່ອນການປ່ຽນແປງທີ່ອາດສົ່ງຜົນກະທົບດັ່ງກ່າວ.

ການນຳໃຊ້

ຂ້ອຍຈະກວດສອບການແປຂອງຄົນອື່ນໄດ້ແນວໃດ?

  • ມີຂັ້ນຕອນການເຮັດວຽກທີ່ອີງໃສ່ການກວດສອບຫຼາຍຢ່າງທີ່ມີໃຫ້ໃນ Weblate, ເບິ່ງ ຂັ້ນຕອນການເຮັດວຽກຂອງການແປ.

  • ເຈົ້າສາມາດສະໝັກຮັບການປ່ຽນແປງໃດໆທີ່ເຮັດໃນ ການແຈ້ງເຕືອນ ແລະ ຈາກນັ້ນກວດສອບການປະກອບສ່ວນຂອງຄົນອື່ນໃນຂະນະທີ່ພວກມັນເຂົ້າມາທາງອີເມວ.

  • ມີເຄື່ອງມືກວດສອບຢູ່ທີ່ດ້ານລຸ່ມຂອງມຸມມອງການແປ, ເຊິ່ງເຈົ້າສາມາດເລືອກ browse ການແປທີ່ເຮັດໂດຍຄົນອື່ນຕັ້ງແຕ່ວັນທີທີ່ກຳນົດ.

ຂ້ອຍຈະໃຫ້ຄຳຕິຊົມກ່ຽວກັບຂໍ້ຄວາມຕົ້ນສະບັບໄດ້ແນວໃດ?

ໃນແຖບ context ດ້ານລຸ່ມການແປ, ເຈົ້າສາມາດໃຊ້ແຖບ Comments ເພື່ອໃຫ້ຄຳຕິຊົມກ່ຽວກັບຂໍ້ຄວາມຕົ້ນສະບັບ, ຫຼື ປຶກສາຫາລືກັບຜູ້ແປອື່ນໆ.

ຂ້ອຍຈະໃຊ້ການແປທີ່ມີຢູ່ແລ້ວໃນຂະນະທີ່ແປໄດ້ແນວໃດ?

  • ການແປທັງໝົດພາຍໃນ Weblate ສາມາດຖືກນຳໃຊ້ໄດ້ຂໍຂອບໃຈກັບ translation memory ທີ່ແບ່ງປັນກັນ.

  • ເຈົ້າສາມາດນຳເຂົ້າໄຟລ໌ translation memory ທີ່ມີຢູ່ເຂົ້າໃນ Weblate.

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

  • ເຈົ້າສາມາດຕັ້ງຄ່າ tmserver ດ້ວຍຖານຂໍ້ມູນທັງໝົດທີ່ເຈົ້າມີ ແລະ ໃຫ້ Weblate ໃຊ້ງານມັນ. ນີ້ແມ່ນດີເມື່ອເຈົ້າຕ້ອງການໃຊ້ງານມັນຫຼາຍຄັ້ງໃນລະຫວ່າງການແປ.

  • ອີກທາງເລືອກໜຶ່ງຄືການແປໂຄງການທີ່ກ່ຽວຂ້ອງທັງໝົດໃນ Weblate instance ດຽວ, ເຊິ່ງຈະເຮັດໃຫ້ມັນດຶງການແປຈາກໂຄງການອື່ນໂດຍອັດຕະໂນມັດເຊັ່ນກັນ.

Weblate ອັບເດດໄຟລ໌ການແປນອກເໜືອຈາກການແປບໍ?

Weblate ພະຍາຍາມຈຳກັດການປ່ຽນແປງໃນໄຟລ໌ການແປໃຫ້ໜ້ອຍທີ່ສຸດ. ສຳລັບບາງຮູບແບບໄຟລ໌ ມັນອາດນຳໄປສູ່ການຈັດຮູບແບບໄຟລ໌ໃໝ່ຢ່າງບໍ່ໄດ້ຕັ້ງໃຈ. ຖ້າເຈົ້າຕ້ອງການຮັກສາຮູບແບບໄຟລ໌ຕາມວິທີຂອງເຈົ້າ, ກະລຸນາໃຊ້ pre-commit hook ສຳລັບສິ່ງນັ້ນ.

ຂ້ອຍຈະ merge ໄຟລ໌ POT ທີ່ອັບເດດແລ້ວກັບການແປ PO ໄດ້ແນວໃດ?

ເບິ່ງ ການອັບເດດໄຟລ໌ພາສາເປົ້າໝາຍ ສຳລັບຂໍ້ມູນກ່ຽວກັບການອັບເດດໄຟລ໌ PO ເມື່ອ template POT ປ່ຽນແປງ.

ນິຍາມພາສາມາຈາກໃສ ແລະ ຂ້ອຍຈະເພີ່ມຂອງຕົນເອງໄດ້ແນວໃດ?

ຊຸດນິຍາມພາສາພື້ນຖານຖືກລວມຢູ່ໃນ Weblate ແລະ Translate-toolkit. ນີ້ກວມເອົາຫຼາຍກວ່າ 150 ພາສາ ແລະ ລວມເຖິງຂໍ້ມູນກ່ຽວກັບຮູບແບບພະຫຸພົດ ຫຼື ທິດທາງຂໍ້ຄວາມ.

ເຈົ້າມີອິດສະຫຼະໃນການກຳນົດພາສາຂອງເຈົ້າເອງໃນ administrative interface, ເຈົ້າພຽງແຕ່ຕ້ອງໃຫ້ຂໍ້ມູນກ່ຽວກັບມັນ.

Weblate ສາມາດເນັ້ນການປ່ຽນແປງໃນຂໍ້ຄວາມ fuzzy ໄດ້ບໍ?

Weblate ຮອງຮັບສິ່ງນີ້, ຢ່າງໃດກໍຕາມ ມັນຕ້ອງການຂໍ້ມູນເພື່ອສະແດງຄວາມແຕກຕ່າງ.

ສຳລັບໄຟລ໌ Gettext PO, ເຈົ້າຕ້ອງສົ່ງ parameter --previous ໄປຍັງ msgmerge ເມື່ອອັບເດດໄຟລ໌ PO, ຕົວຢ່າງ:

msgmerge --previous -U po/cs.po po/phpmyadmin.pot

ສຳລັບການແປແບບ monolingual, Weblate ສາມາດຊອກຫາຂໍ້ຄວາມກ່ອນໜ້າໂດຍ ID, ດັ່ງນັ້ນມັນຈຶ່ງສະແດງຄວາມແຕກຕ່າງໂດຍອັດຕະໂນມັດ.

ເປັນຫຍັງ Weblate ຈຶ່ງຍັງສະແດງຂໍ້ຄວາມການແປເກົ່າທັງທີ່ຂ້ອຍອັບເດດ template ແລ້ວ?

Weblate ບໍ່ພະຍາຍາມປັບປ່ຽນໄຟລ໌ການແປໃນທາງໃດທາງໜຶ່ງນອກເໜືອຈາກການອະນຸຍາດໃຫ້ຜູ້ແປເຮັດວຽກ. ດັ່ງນັ້ນມັນຈຶ່ງບໍ່ອັບເດດໄຟລ໌ທີ່ແປໄດ້ເມື່ອ template ຫຼື source code ຖືກປ່ຽນແປງ. ເຈົ້າພຽງແຕ່ຕ້ອງເຮັດສິ່ງນີ້ດ້ວຍຕົນເອງ ແລະ push ການປ່ຽນແປງໄປຍັງ repository, ຈາກນັ້ນ Weblate ຈະຮັບເອົາການປ່ຽນແປງໂດຍອັດຕະໂນມັດ.

Note

ມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະ merge ການປ່ຽນແປງທີ່ເຮັດໃນ Weblate ກ່ອນອັບເດດໄຟລ໌ການແປ, ຖ້າບໍ່ດັ່ງນັ້ນເຈົ້າມັກຈະຈົບລົງດ້ວຍ conflict ບາງຢ່າງທີ່ຈະຕ້ອງ merge.

ຈະຈັດການກັບການປ່ຽນຊື່ໄຟລ໌ການແປແນວໃດ?

ເມື່ອປ່ຽນຊື່ໄຟລ໌ໃນ repository, ມັນອາດເກີດຂຶ້ນໄດ້ວ່າ Weblate ເຫັນສິ່ງນີ້ເປັນການລຶບ ແລະ ເພີ່ມໄຟລ໌. ສິ່ງນີ້ສາມາດນຳໄປສູ່ການສູນເສຍປະຫວັດຂໍ້ຄວາມ, ຄວາມຄິດເຫັນ ແລະ ຄຳແນະນຳ.

ເພື່ອຫຼີກລ່ຽງສິ່ງນັ້ນ, ໃຫ້ປະຕິບັດການປ່ຽນຊື່ໃນຂັ້ນຕອນຕໍ່ໄປນີ້:

  1. ລັອກອົງປະກອບການແປໃນ ການຈັດການ Local VCS repository.

  2. Commit ການປ່ຽນແປງທີ່ຍັງຄ້າງໃນ ການຈັດການ Local VCS repository.

  3. Merge ການປ່ຽນແປງຂອງ Weblate ເຂົ້າໃນ upstream repository.

  4. ປິດການຮັບການອັບເດດຜ່ານ hooks ໂດຍໃຊ້ ເປີດໃຊ້ Hooks.

  5. ດຳເນີນການປ່ຽນຊື່ໄຟລ໌ໃນ repository.

  6. ອັບເດດການຕັ້ງຄ່າອົງປະກອບໃຫ້ກົງກັບຊື່ໄຟລ໌ໃໝ່.

  7. ເປີດໃຊ້ update hooks ແລະ ປົດລັອກອົງປະກອບ.

Hint

ການສຳຮອງຂໍ້ມູນລະດັບໂປຣເຈັກ ອາດເປັນປະໂຫຍດທີ່ຈະປະຕິບັດກ່ອນການປ່ຽນແປງທີ່ອາດສົ່ງຜົນກະທົບດັ່ງກ່າວ.

ການແກ້ໄຂບັນຫາ

Requests ບາງຄັ້ງລົ້ມເຫຼວດ້ວຍ error "too many open files"

ສິ່ງນີ້ເກີດຂຶ້ນບາງຄັ້ງເມື່ອ Git repository ຂອງເຈົ້າໃຫຍ່ເກີນໄປ ແລະ ເຈົ້າມີພວກມັນຫຼາຍ. ການບີບອັດ Git repositories ຈະປັບປຸງສະຖານະການນີ້ໃຫ້ດີຂຶ້ນ.

ວິທີທີ່ງ່າຍທີ່ສຸດໃນການເຮັດສິ່ງນີ້ຄື run:

# Go to DATA_DIR directory
cd data/vcs
# Compress all Git repositories
for d in */* ; do
    pushd $d
    git gc
    popd
done

See also

DATA_DIR

ເມື່ອເຂົ້າເຖິງເວັບໄຊ, ຂ້ອຍໄດ້ຮັບ error "Bad Request (400)"

ສິ່ງນີ້ມັກເກີດຈາກ ALLOWED_HOSTS ທີ່ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ. ມັນຕ້ອງມີ hostname ທັງໝົດທີ່ເຈົ້າຕ້ອງການເຂົ້າເຖິງໃນ Weblate ຂອງເຈົ້າ. ຕົວຢ່າງ:

ALLOWED_HOSTS = ["weblate.example.com", "weblate", "localhost"]

"There are more files for the single language (en)" ໝາຍຄວາມວ່າແນວໃດ?

ສິ່ງນີ້ມັກເກີດຂຶ້ນເມື່ອເຈົ້າມີໄຟລ໌ການແປສຳລັບພາສາຕົ້ນສະບັບ. Weblate ຕິດຕາມຂໍ້ຄວາມຕົ້ນສະບັບ ແລະ ຈອງພາສາຕົ້ນສະບັບໄວ້ສຳລັບສິ່ງນີ້. ໄຟລ໌ເພີ່ມເຕີມສຳລັບພາສາດຽວກັນຈະບໍ່ຖືກປະມວນຜົນ.

  • ໃນກໍລະນີທີ່ຕ້ອງການການແປເປັນພາສາຕົ້ນສະບັບ, ກະລຸນາປ່ຽນ ພາສາຕົ້ນທາງ ໃນການຕັ້ງຄ່າອົງປະກອບ. ເຈົ້າອາດຕ້ອງການໃຊ້ English (Developer) ເປັນພາສາຕົ້ນສະບັບ, ຫຼື ນຳໃຊ້ ປະຕູຄຸນນະພາບສຳລັບຂໍ້ຄວາມຕົ້ນສະບັບ.

  • ໃນກໍລະນີທີ່ໄຟລ໌ການແປສຳລັບພາສາຕົ້ນສະບັບບໍ່ຈຳເປັນ, ກະລຸນາລຶບມັນອອກຈາກ repository.

  • ໃນກໍລະນີທີ່ໄຟລ໌ການແປສຳລັບພາສາຕົ້ນສະບັບຈຳເປັນ, ແຕ່ຄວນຖືກລະເລີຍໂດຍ Weblate, ກະລຸນາປັບ ຕົວຢັ້ງຢືນພາສາ ເພື່ອຍົກເວັ້ນມັນ.

Hint

ເຈົ້າອາດໄດ້ຮັບຂໍ້ຄວາມ error ທີ່ຄ້າຍຄືກັນສຳລັບພາສາອື່ນເຊັ່ນກັນ. ໃນກໍລະນີນັ້ນ ເຫດຜົນທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດແມ່ນໄຟລ໌ຫຼາຍໄຟລ໌ map ໄປຍັງພາສາດຽວໃນ Weblate.

ສິ່ງນີ້ສາມາດເກີດຂຶ້ນໄດ້ໂດຍການໃຊ້ລະຫັດພາສາທີ່ຫຼ້າສະໄໝຮ່ວມກັບອັນໃໝ່ (ja ແລະ jp ສຳລັບພາສາຍີ່ປຸ່ນ) ຫຼື ການລວມເອົາລະຫັດສະເພາະປະເທດ ແລະ ລະຫັດທົ່ວໄປ (fr ແລະ fr_FR). ເບິ່ງ ການແຍກລະຫັດພາສາ (Parsing) ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ.

ຄຸນສົມບັດ

Weblate ຮອງຮັບ VCS ອື່ນນອກຈາກ Git ແລະ Mercurial ບໍ?

ປະຈຸບັນ Weblate ບໍ່ມີການຮອງຮັບແບບ native ສຳລັບສິ່ງໃດນອກເໜືອຈາກ Git (ພ້ອມການຮອງຮັບແບບຂະຫຍາຍສຳລັບ GitHub Pull request, ຄຳຮ້ອງຂໍການກວດສອບ Gerrit, ແລະ Subversion) ແລະ Mercurial, ແຕ່ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນ backends ສຳລັບ VCS ອື່ນໆ.

Weblate ຍັງຮອງຮັບການເຮັດວຽກແບບ VCS-less, ເບິ່ງ ໄຟລ໌ພາຍໃນເຄື່ອງ.

Note

ສຳລັບການຮອງຮັບ native ຂອງ VCS ອື່ນໆ, Weblate ຕ້ອງການການໃຊ້ distributed VCS, ແລະ ອາດຈະສາມາດປັບໃຫ້ເຮັດວຽກກັບສິ່ງໃດກໍໄດ້ນອກເໜືອຈາກ Git ແລະ Mercurial, ແຕ່ຕ້ອງມີຄົນມາຈັດຕັ້ງປະຕິບັດການຮອງຮັບນີ້.

Weblate ໃຫ້ກຽດ (credit) ຜູ້ແປແນວໃດ?

ທຸກການປ່ຽນແປງທີ່ເຮັດໃນ Weblate ຈະຖືກ committed ເຂົ້າໃນ VCS ພາຍໃຕ້ຊື່ຜູ້ແປ. ວິທີນີ້ທຸກການປ່ຽນແປງມີ authorship ທີ່ເໝາະສົມ, ແລະ ເຈົ້າສາມາດຕິດຕາມມັນໄດ້ໂດຍໃຊ້ເຄື່ອງມື VCS ມາດຕະຖານທີ່ເຈົ້າໃຊ້ສຳລັບ code.

ນອກຈາກນັ້ນ, ເມື່ອຮູບແບບໄຟລ໌ການແປຮອງຮັບ, file headers ຈະຖືກອັບເດດເພື່ອລວມເອົາຊື່ຂອງຜູ້ແປ.

ເປັນຫຍັງ Weblate ຈຶ່ງບັງຄັບໃຫ້ສະແດງໄຟລ໌ PO ທັງໝົດໃນ tree ດຽວ?

Weblate ຖືກອອກແບບມາໃນທາງທີ່ໄຟລ໌ PO ທຸກໄຟລ໌ຖືກສະແດງເປັນອົງປະກອບດຽວ. ນີ້ມີປະໂຫຍດສຳລັບຜູ້ແປ, ເພື່ອໃຫ້ພວກເຂົາຮູ້ວ່າພວກເຂົາກຳລັງແປຫຍັງແທ້ໆ.

Changed in version 4.2: ຜູ້ແປສາມາດແປອົງປະກອບທັງໝົດຂອງໂຄງການເປັນພາສາສະເພາະໂດຍລວມໄດ້.

ເປັນຫຍັງ Weblate ຈຶ່ງໃຊ້ລະຫັດພາສາເຊັ່ນ sr_Latn ຫຼື zh_Hant?

ເຫຼົ່ານີ້ແມ່ນລະຫັດພາສາທີ່ກຳນົດໂດຍ RFC 5646 ເພື່ອລະບຸໃຫ້ດີຂຶ້ນວ່າພວກມັນເປັນພາສາທີ່ແຕກຕ່າງກັນແທ້ໆ ແທນທີ່ຈະເປັນ modifiers ທີ່ໃຊ້ຜິດໆໃນເມື່ອກ່ອນ (ສຳລັບຕົວແປ @latin) ຫຼື ລະຫັດປະເທດ (ສຳລັບພາສາຈີນ).

Weblate ຍັງເຂົ້າໃຈລະຫັດພາສາແບບເກົ່າ (legacy) ແລະ ຈະ map ພວກມັນໄປຍັງອັນປັດຈຸບັນ - ຕົວຢ່າງ sr@latin ຈະຖືກຈັດການເປັນ sr_Latn ຫຼື zh@CN ເປັນ zh_Hans.

Note

Weblate ໃຊ້ລະຫັດພາສາແບບ POSIX ທີ່ມີ underscore ເປັນຄ່າເລີ່ມຕົ້ນ, ເບິ່ງ ຄຳນິຍາມພາສາ ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ.