Halo @anon044949
Jadi, kami telah mengadakan diskusi dengan berbagai konsultan tentang cara membantu penerjemah menghasilkan draf yang lebih baik. Jika kami dapat menghindari masalah sejak awal, itu akan memudahkan segalanya. Jika kami tahu beberapa hal tentang cara kerja bahasa tertentu, maka kami dapat memasukkan prompt yang spesifik untuk preferensi linguistik tersebut. Kemudian tim dapat menerjemahkannya dengan benar sebelum sampai pada pemeriksaan konsultan.
Tiga contoh:
Beberapa tim memiliki kesulitan membedakan pertanyaan retoris dari pertanyaan konten. Ini berarti konsultan harus terus-menerus menanyakan hal yang sama di setiap instansinya. Tetapi jika saya bisa membuat catatan konsultan yang mengatakan “Pertanyaan Retoris” dan menerapkannya pada ratusan instansinya, maka tim akan jauh lebih mungkin melakukannya dengan benar sejak awal.
Dalam bahasa Inggris, secara gramatikal mengatakan, “Untuk membeli susu, saya pergi ke toko.” tetapi lebih alami untuk mengatakan, “Saya pergi ke toko untuk membeli susu.” Bahasa berbeda dalam urutan frasa yang disukai tetapi karena beban kognitif menerjemah, penerjemah sering tidak mempertimbangkan kemungkinan tersebut saat mereka membuat draf. Salah satu tim saya dapat mengikuti urutan kata Spanyol dan itu sepenuhnya gramatikal, tetapi dalam keadaan tertentu lebih alami untuk menggunakan urutan kata yang berbeda. Jika saya menggunakan <LDGNT = Reason-Result Frame> dan <LDhb = Reason-Result Frame> saya bisa membuat empat atau lima ratus catatan di mana mereka mungkin tidak ingin mengikuti urutan kata Spanyol.
teks sumber yang paling umum dalam bahasa Spanyol adalah Reina-Valera, yang setara dengan KJV (atau mungkin NKJV). Tetapi ada banyak instans di mana itu menyimpang dari apa yang disepakati oleh sebagian besar sarjana sebagai teks asli. (Seorang teman saya yang mengajar di seminari tidak membiarkan mahasiswanya menggunakannya di kelas karena dia lelah mengoreksi mereka.) Tim seharusnya membandingkan versi dan memperhatikan semua perbedaan ini, tetapi kenyataannya mereka biasanya melewatkannya. Saya telah memulai proyek catatan konsultan yang khusus untuk masalah tekstual dalam Reina-Valera karena mereka mungkin 10-15% dari semua catatan saya untuk proyek tersebut. Jika saya bisa menemukan daftar perbedaan ini, itu akan menghemat waktu saya berjam-jam, apalagi waktu untuk tim saya.
Masing-masing dari ini bisa menjadi proyek catatan konsultan tersendiri yang dapat dibagikan dengan puluhan (jika bukan ratusan) tim yang menangani masalah-masalah spesifik ini. Tentu saja ada banyak masalah lain yang akan bekerja dengan baik, ini hanya beberapa yang terlintas di benak saya.
Banyak tim tidak memiliki keterampilan teknis yang hebat sehingga filter visual Logos bukan pilihan yang bagus. Sulit untuk membuat mereka menggunakan komentar dan sumber daya yang mereka miliki, jadi menambahkan file lain untuk diperiksa mungkin tidak akan terintegrasi ke dalam alur kerja mereka. Ada beberapa pembicaraan tentang ini menjadi opsi di dasbor CLEAR, tetapi itu bergantung pada apakah itu diprogram dan apakah tim menggunakan dasbor dalam pembuatan draf. Jadi ide terbaik saya sejauh ini adalah proyek catatan konsultan yang spesifik masalah, dan Anda bisa melihat mengapa saya lebih suka membuat catatan sekali daripada 400 kali.
Juga, untuk apa pun, saya hanya bereksperimen di proyek saya sendiri yang saya atur khusus untuk pengujian. Saya tahu bahaya mengutak-atik kode dan saya melakukan perubahan inkremental yang mudah saya batalkan. Atau jika saya benar-benar mengacaukannya (belum pernah terjadi) maka saya bisa menghapus proyek tanpa kerugian.
Hi @anon044949
So, we have been having discussions with various consultants about how to help translators produce better drafts. If we can avoid problems in the first place, it makes everything else easier. If we know some things about how a particular language works then we can put in prompts that are specific to those linguistic preferences. Then the team can correctly translate it before getting to the consultant check.
Three examples:
Some teams have a difficult time distinguishing rhetorical questions from content questions. This means that the consultant has to keep asking about them the same question at every instance. But if I could make a consultant note saying “Rhetorical Question” and apply it to the hundreds of instances, then teams would be much more likely to do it right from the start.
In English it is grammatical to say, “To buy milk, I went to the store.” but it is more natural to say, “I went to the store to buy milk.” Languages differ on preferred phrase order but because of the cognitive load of translating, translators often don’t consider the possibility while they’re drafting. One of my teams can follow the Spanish word order and it is perfectly grammatical, but in certain circumstances it is more natural to use a different word order. If I use <LDGNT = Reason-Result Frame> and <LDhb = Reason-Result Frame> I could make four or five hundred notes where they probably don’t want to follow the Spanish word order.
The most common source text in Spanish is the Reina-Valera, which is equivalent to the KJV (or maybe NKJV). But there are lots of instances where it deviates from what most scholars agree is the original text. (A friend of mine who teaches seminary won’t let his students use it in class because he got tired of correcting them.) The teams should be comparing versions and noticing all these differences, but the reality is that they usually miss them. I have started a consultant note project just dedicated to the textual issues in the Reina-Valera because they’re maybe 10-15% of all my notes for the project. If I could find a list of these differences, it would save me hours, let alone the time for my team.
These could each be their own consultant note project which could be shared with the dozens (if not hundreds) of teams dealing with these specific issues. Of course there are many other issues that would work well, these are just a few off the top of my head.
Many teams don’t have great tech skills so Logos visual filters aren’t a great option. It is hard to get them to use the commentaries and resources that they have, so adding another file to check probably wouldn’t get integrated into their workflow. There is some talk about this being an option in the CLEAR dashboard, but that is dependent on whether it gets programmed in and whether teams use the dashboard in drafting. So my best idea so far is issue-specific consultant notes projects, and you can see why I’d rather make a note once instead of 400 times.
Also, for what it is worth, I only experiment on my own projects that I set up specifically to test on. I know the dangers of messing with code and I do incremental changes that I can easily undo. Or if I really mess it up (hasn’t happened yet) then I can delete the project with no harm done.
Diterjemahkan secara otomatis dari English Tampilkan asli
