0 suara
344 tampilan

Saya sudah lama pusing dengan masalah ini, dan baru saja menemukan solusinya, jadi saya membagikannya di sini jika ada orang lain yang juga mencoba mencegah teks tertentu dari transliterasi otomatis. Solusi ini terasa tidak intuitif dan agak janggal.

Intinya:

Jika Anda memiliki teks non-bahasa daerah (non-vernacular) yang tidak boleh ditransliterasi otomatis oleh pengonversi encoding, melainkan harus diterbitkan dalam encoding aslinya, bungkuslah dengan gaya karakter kustom, dan berikan gaya kustom tersebut properti nonpublishable.

Ya, propertinya adalah nonpublishable, bukan nonvernacular, yang mungkin terlihat lebih tepat. Properti nonvernacular sebenarnya tidak memengaruhi apa yang ditransliterasi, dan properti nonpublishable saat ini tidak memengaruhi apa yang diterbitkan, setidaknya tidak oleh Publishing Assistant.

Latar belakang detail:

Saya akan melakukan typesetting untuk proyek yang ditransliterasi otomatis. Proyek ini mengandung kata-kata tertentu dalam bahasa nasional. Kata-kata ini dapat ditemukan dalam entri glosarium, materi pengantar, dan catatan kaki, dan diberi tag di dalam penanda \znp …\znp*, yang telah saya definisikan dalam custom.sty sebagai gaya karakter nonvernacular, publishable, karena memang itulah fungsinya.

Di proyek utama/sumber, teks bahasa daerah dan teks bahasa nasional keduanya menggunakan sistem tulisan yang sama. Di proyek yang ditransliterasi otomatis, teks bahasa daerah harus dikonversi menjadi aksara tradisional yang hanya digunakan untuk bahasa ini, tetapi teks dalam bahasa nasional harus tetap seperti aslinya dalam aksara aslinya. (Aksara tradisional tersebut tidak dapat merepresentasikan bunyi retrofleks yang ditemukan dalam bahasa nasional, dan akan aneh jika melihat bahasa nasional dalam aksara tradisional bahasa daerah tersebut.)

Tetapi menandai teks seperti itu sebagai nonvernacular tidak berpengaruh dalam mencegah transliterasi.

Peta TECkit juga tidak bisa diperintahkan untuk mengabaikan teks yang dibungkus penanda \znp …\znp*, karena penanda itu sendiri tidak diteruskan ke peta untuk diproses. (Kemungkinan dulu bisa, karena dokumentasi Bantuan Paratext masih mengatakan, “Pastikan file TECkit.map yang Anda gunakan mempertahankan penanda USFM agar tidak dikonversi.”)

Solusi yang janggal adalah mengubah properti publishable menjadi nonpublishable. Hal ini tidak mencegah Publishing Assistant untuk menerbitkannya.

Saya tidak tahu apakah hal ini akan mengganggu jalur output lain (SAB / Print Draft / PtxPrint / YouVersion via DBL), baik saat ini maupun di masa depan, di mana teks yang tidak dapat diterbitkan (unpublishable) mungkin akan dibuang secara diam-diam, jadi ini pasti menjadi kekhawatiran dengan solusi sementara ini.

Di luar fakta bahwa nonpublishable membebaskan teks dari transliterasi otomatis, saya tidak jelas efek lain apa yang mungkin dimiliki oleh kedua properti ini. Apakah ada dokumentasi di suatu tempat yang menjelaskan hal ini?

Diterjemahkan secara otomatis dari English
Paratext oleh (286 poin)
ditampilkan kembali | 344 tampilan

2 Jawaban

+1 suara
Jawaban terbaik

PTXprint (atau lebih tepatnya, makro TeX ptx2pdf yang digunakannya) akan memperlakukan apa pun yang ditandai nonpublishable sebagai komentar hampir-hampir. Program python mungkin juga menerapkan modifikasinya sendiri; saya tidak tahu.

Gaya paragraf dan karakter nonpublishable tidak akan menghasilkan output, memang ini adalah salah satu cara untuk menekan nomor ayat, dll.
Saya mengatakan hampir komentar, karena tidak ada yang diperlakukan sebagai komentar sebenarnya: semuanya tetap dibaca dan diinterpretasikan, hanya saja di akhir paragraf/gaya karakter, materi tersebut dibuang.
Jadi Anda tidak bisa menempatkan USFM \invalid di sana, dan milestone berjangkauan yang dimulai di teks nonpublishable dan tidak diakhiri akan tetap berlaku setelahnya.

Namun, mengingat urutan pemuatan stylesheet dengan PTXprint, Anda dapat mengatur sesuatu menjadi nonpublishable di custom.sty dan kemudian menimpa pengaturan tersebut di stylesheet berikutnya.

Diterjemahkan secara otomatis dari English
oleh (294 poin)

Ah, itu bagus untuk diketahui. Terima kasih!

Diterjemahkan secara otomatis dari English
+1 suara

Ini memang tidak intuitif dan tidak bekerja seperti ini di masa lalu. Jadi saya percaya ini pasti bug. Di proyek-proyek sebelumnya, saya cukup berhasil menggunakan \tl…\tl* (Kata yang Ditransliterasi) untuk memblokir konversi yang memiliki karakteristik publishable nonvernacular. Saya juga menggunakan karakteristik ini untuk gaya paragraf kustom di bagian depan dan belakang melalui stylesheet frtback.sty. Dan nonpublishable TIDAK SEHARUSNYA muncul melalui Publishing Assistant ke InDesign.

Semoga perilaku ini dapat diperbaiki, jadi Anda harus fleksibel dengan markup Anda sampai saat itu…

Salam,

Diterjemahkan secara otomatis dari English
oleh (1,3k poin)
ditampilkan kembali

Terima kasih, Shegnada. Markup aslinya memang \tl ...\tl*, yang mungkin mencerminkan bahwa pada suatu titik di masa lalu, itu berfungsi di proyek ini untuk mencegah transliterasi otomatis. (Perjanjian Baru diterbitkan beberapa tahun yang lalu, dan sekarang kami mengerjakan Alkitab lengkap.) Dalam hal itu, bug ini adalah regresi, sesuatu yang rusak ketika sesuatu lain sedang ditangani. Saya telah melaporkannya sebagai PTXS-31555. Setelah diperbaiki, itu akan menjadi masalah sederhana untuk memperbarui definisi \znp yang saya miliki di custom.sty dan frtbak.sty untuk mengganti nonpublishable dengan publishable.

Tetapi sekarang saya bertanya-tanya apakah fungsionalitasnya sengaja diubah berdasarkan alasan seseorang bahwa teks \tl seharusnya diproses melalui pengonversi. Proyek ini sejak itu telah menggunakan penanda \tl di Perjanjian Lama untuk menandai kata-kata yang ditransliterasi dari bahasa sumber, seperti purim dan mene, tekel, parsin. Niat tim penerjemah adalah bahwa kata-kata ini akan diproses oleh pengonversi agar dalam aksara yang sama dengan proyek, tetapi dicetak miring dalam aksara mana pun itu. Jadi saya rasa ketika bug ini diperbaiki, kami juga perlu mengingat untuk mendefinisikan ulang \tl sebagai vernacular di proyek ini, untuk memastikan bahwa itu memang diproses oleh pengonversi. Apakah itu terdengar seperti cara yang benar untuk melakukannya?

Saya masih sangat ingin menemukan dokumentasi tentang efek tepat apa yang dimaksudkan oleh properti publishable/nonpublishable dan vernacular/nonvernacular. Sejauh ini saya hanya tahu bahwa nonpublishable seharusnya menghasilkan teks yang menghindari konversi encoding dan juga menghindari terlihat dalam publikasi. Saya percaya bahwa nonvernacular dimaksudkan untuk menghindari konversi encoding (meskipun itu rusak), dan saya tidak menyadari efek lain yang dimaksudkan. Saya bertanya-tanya apakah salah satunya memiliki pengaruh pada daftar kata ejaan, inventaris karakter, dll?

Diterjemahkan secara otomatis dari English

Saya pikir selama Anda menggunakan stylesheet kustom, misalnya custom.sty dalam kasus Anda dan mendokumentasikan dengan hashtag apa yang Anda lakukan dan mengapa DAN menambahkan catatan Paratext di lokasi \tl pertama tentang perilaku yang Anda cari, Anda seharusnya baik-baik saja di jalur PubAssist/InDesign Anda.

Tetapi balasan yang Anda terima untuk posting asli Anda menunjukkan bahwa jika Anda memiliki output lain dalam pikiran, Anda juga harus menguji mereka dan mungkin penanda kustom akan melayani Anda lebih baik. Saya tidak benar-benar tahu.

Anda harus mempertimbangkan bahwa Anda memiliki dua, atau mungkin seperti yang biasanya saya miliki, tiga, proyek yang terlibat. Proyek asli, proyek yang dikonversi secara otomatis (tidak dapat diedit), dan (saya sarankan) proyek ketiga yang digunakan untuk penerbitan yang mendapatkan teksnya dari impor dari proyek yang dikonversi. Masing-masing proyek ini dapat memiliki stylesheet kustom yang berbeda dan meskipun penting bahwa proyek pertama memiliki karakteristik gaya yang akan membuat pengonversi bekerja dengan benar, stylesheet dari proyek yang Anda terbitkan dapat berbeda dari ini dan mereka adalah satu-satunya yang memengaruhi output yang diterbitkan. Jadi Anda memiliki beberapa fleksibilitas, terutama jika Anda menggunakan proyek ketiga itu. Saya bisa berbicara dengan Anda lebih lanjut di luar daftar jika Anda suka tentang keuntungan lain dari proyek ketiga, tetapi saya akan menganggap proyek kedua dan ketiga sebagai output semata, dan dokumentasi, dll., harus selalu ditemukan di proyek asli.

Salam,

Diterjemahkan secara otomatis dari English

Pertanyaan terkait

+1 suara
2 jawaban 302 tampilan
A few days ago, I painfully found out that the tag nonpublishable inside a project usfm.sty is important and ... about PT8 and about using its features correctly and properly.
Tim 934 bertanya Feb 1, 2019
0 suara
0 jawaban 169 tampilan
This topic only covers the addition of a TECkit map encoding converter. If the converter for the language ... Transliteration (using Encoding Converter) for an existing project.
[Expert]
anon421222
735
bertanya Feb 23, 2017
+1 suara
3 jawaban 437 tampilan
Exporting the Wordlist to HTML is a nice feature, except that for many users including me, working with HTML is ... that are currently marked as spelled correctly in PT? anon101508
anon101508 117 bertanya Mar 11, 2019
0 suara
1 jawaban 62 tampilan
Akhirnya saya berhasil menampilkan batas judul bagian dan batas halaman dengan benar menggunakan diakritik merah dalam proyek ... teks Alkitab, tetapi tidak di halaman judul awal
Mark Skinner 104 bertanya Feb 19, 2025
0 suara
1 jawaban 189 tampilan
Saya terus-menerus menemui pesan kesalahan berikut yang menghalangi saya untuk mengekspor ke pdf: Marker cannot occur ... tidak berhasil. Apakah ada yang tahu cara memperbaikinya?
anon233143 252 bertanya Jun 25, 2021
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
Dear friends, since God so loved us, we also ought to love one another.
1 John 4:11
3,047 pertanyaan
6,007 jawaban
5,672 komentar
2,027 pengguna