Le problème de base ici est que nous travaillons dans un monde multilingue (grec, hébreu, langue locale, langue de communication plus large), mais l'éditeur dans Paratext ne le reconnaît pas. Donc « tout » dans le projet X est dans la langue X. Et cette approche est tout simplement trop simpliste.
Il est nécessaire d'avoir un moyen de marquer le grec, l'hébreu et le LWC, avec des styles SFM uniques (pour chacun) et que ceux-ci soient maintenus séparément dans la liste « Valid/Invalid ». Et NE PAS être mélangés avec l'inventaire des caractères, de l'orthographe ou de la liste des mots de la langue X. (Même la ponctuation LWC valide pourrait être invalide pour la langue X.)
Là où nous travaillons, aujourd'hui, nous pourrions marquer une lettre étrange comme valide trouvée dans un mot du LWC dans une note de bas de page. Mais est-ce que faire cela ouvre la possibilité que quelqu'un puisse introduire une faute de frappe dans la langue X en utilisant ce caractère « valide », parce que nous l'avons marqué comme valide ? C'est-à-dire qu'il est valide pour le LWC, mais il est INVALIDE s'il est utilisé dans la langue X.
Alors comment différencions-nous cela ? Et pourquoi ne pouvons-nous pas simplement marquer ceux-ci comme différentes langues ? Cela semble être la solution la plus évidente. Tout autre éditeur raisonnablement puissant que je connais reconnaît la « langue », nous devrions sûrement le faire dans ce métier de traduction.
Admettons que ce n'est pas nécessaire souvent, mais c'est nécessaire assez souvent pour qu'une solution serait très utile. (Et je suis d'accord avec anon848905 pour dire que simplement les « ignorer » est une solution moins qu'idéale.) Ceux-ci sont « valides » dans certains cas ; nous avons besoin que Paratext soit assez intelligent pour reconnaître le contexte (les crochets SFM) et les valider en fonction de leur sous-ensemble particulier.
The basic problem here is we are working in a multilingual world (Greek, Hebrew, local language, language of wider communication), but the editor in Paratext does not recognize that. So “everything” in project X is in the X language. And this approach is just too simplistic.
What is needed is a way to mark Greek, Hebrew, and LWC, with unique SFM styles (for each) and these be maintained separately in the “Valid/Invalid” list. And NOT be mixed in with the X Language’s character, spelling, or wordlist inventories. (Even valid LWC punctuation might be invalid for language X.)
Where we work, today we might mark some weird letter as valid found in a word from the LWC in a footnote. But does doing this open the possibility that someone may introduce a typo in X language using that “valid” character, because we marked it as valid? I.e. it is valid for the LWC, but it is INVALID if used in the X Language.
So how do we differentiate this? And why can’t we just mark these as different languages? That seems the most obvious solution. Every other reasonably powerful editor I know recognizes “language”, surely we should in this business of translation.
Granted, this isn’t needed a lot, but it is needed often enough that a solutions would be very helpful. (And I agree with anon848905 that just “ignoring” them is a less than ideal solution.) These are “valid” in certain cases; we need Paratext to be smart enough to recognize the context (the SFM brackets) and validate them based on their particular subset.
Traduit automatiquement depuis English
