Handling dialect variants

Question

Hi, I have a Paratext user just starting out in a project with two major dialects. The major issue is that they have some words in one dialect that the other dialect speakers do not know, so for those they want to use a different word for each dialect. The plan is to ultimately publish a different version for each dialect, but for now they want to keep it as one paratext project, and only split the dialects after consultant checking.

Right now, they translate according to the first dialect. Then when a word is used that people in the second dialect do not know, they include the word from the second dialect in the text as well, but in brackets next to the word from the first dialect.

My question is whether this is the best way to handle this. Should they continue doing this, or is there another way I should suggest to them (a backslash marker?) that would make it easier at publishing time, and still be easy for the mother tongue translators of both dialects as they draft?

anon609523

Ancienne publication - affichée dans sa langue d'origine

Answer 1

There is a whole other way to do this: the Interlinearizer (on the File menu) has an option for related languages, which basically defaults to glossing one translating with an identical translation. But if you gloss one word as another – i.e. gloss with the word from the second dialect, the IL (Interlinearizer) will remember that, and use it everywhere else. If the word changes (e.g. a suffix is added), you can set the morphology in PT so that the root is recognised as the same; you may still have to gloss each variant of the word separately, but if you do, you only need do it once for each variant.

The IL has the option to output to a second project – and you should do this: create a second project (as a daughter project of the first) and choose this option. The second project will then contain your dialect modification version of the first. You continue to work in the first project, and if you modify a verse, that verse will be reset to “unapproved” status in the IL, and it’s very easy to check all the unapproved verses – or simply re-output the whole book or chapter to the second project if, from experience, you feel you can trust the IL to always get it right.

Another feature that helps when you edit the first project / master project: daughter projects have tick boxes (checkboxes) on every verse, so the second project will have these. You tick the box to confirm that the translation has been done (or that it’s been proof read – it’s your choice). If you edit a verse in the first project, the tick will be removed from that verse in the daughter project, and this can also be helpful in keeping the second project updated when changes are made.

I’m giving a very brief explanation of a rather powerful tool. Either simply try it … or ask me if you have questions.

Ancienne publication - affichée dans sa langue d'origine