Инвентарь символов

Question

Должны ли символы, используемые в иностранных словах (иногда применяемых в сносках), включаться в инвентарь символов? Или есть какой-то способ принять «ошибки», когда они появляются в базовых проверках как недействительные?

Переведено машиной с языка English Показать оригинал

Answer 1

Я присоединяюсь к этому разговору немного поздно, но я полностью согласен с davidc78. USFM должен иметь (минимально) маркер (возможно, \fo … \fo* — «o» для «другой язык») для слов, используемых в сноске, которые на другом языке, будь то греческий, иврит, региональный LWC, национальный язык, международный язык, что угодно. Слова, помеченные таким образом, должны быть исключены из списка слов, а также из проверки символов. Некоторые пользователи могут даже захотеть иметь набор маркеров, например, \foh для ивритских слов, \fog для греческих слов, \foa для арамейских слов, \fon для национального языка, \for для регионального LWC (или, возможно, связанного варианта) и т. д., а также сделать Paratext способным обрабатывать несколько списков слов (местный, греческий, иврит, арамейский и т. д.). Не упростило бы это также связывание Paratext с FLEx, исключая слова, которые пользователь не хочет включать в лексикон FLex? Фактически, наличие нескольких маркеров, как я описал, могло бы позволить связать Paratext с несколькими списками слов внутри Paratext, а возможно, даже с несколькими лексиконами FLex.

Переведено машиной с языка English Показать оригинал

Comments

Позже я осознал, что \tl — это маркер USFM, который можно использовать внутри сноски, чтобы пометить слова с другого языка (будь то библейский язык, национальный язык или что-либо еще). Однако слова, которые я пометил с помощью \tl, все еще появляются в списке слов. Этого я не хочу, и я был бы удивлен, если бы кто-то хотел этого, поскольку это не слова на местном языке. (Если некоторые пользователи хотят видеть такие слова в списке слов, я бы предложил, чтобы Paratext имел возможность генерировать вторичный список слов, содержащий только те слова, которые помечены с помощью \tl.)

Переведено машиной с языка English Показать оригинал

---

Я согласен, что было бы неплохо, если бы Paratext имел возможность различать слова на местном языке и слова на других языках (а также различие в символах). Однако с другой стороны, Paratext проверяет слова, которые существуют (и будут опубликованы) в тексте. Является ли слово местным или нет, не имеет значения для процесса проверки, поскольку необходимо убедиться, что слова написаны правильно и, возможно, правильно дефисованы. Список слов Paratext сообщает о словах, которые существуют в публикуемом тексте.

Переведено машиной с языка English Показать оригинал

---

Хорошая точка зрения.

Переведено машиной с языка English Показать оригинал

Answer 2

anon070973,

По этому вопросу существуют разные мнения, но, я думаю, консенсус состоит в том, что в языковых настройках следует включать только те символы, которые встречаются в данном языке. Поэтому я бы не включал греческие или ивритские символы в языковые настройки, поскольку они не встречаются в этом языке. Однако, если в моем тексте есть слово Cristo, а буква c обычно не встречается в моем языке, я все равно включил бы букву c в свои языковые настройки, поскольку Cristo теперь является словом, «используемым» в моем языке.
Для других иностранных букв вам просто нужно было бы пометить их как допустимые в Инвентаре символов, если они «допустимы» в проекте.

Высказав это мнение, я уверен, что найдутся те, кто будет со мной не согласен по разным причинам.

Переведено машиной с языка English Показать оригинал

Answer 3

Я согласен с anon848905 в том, что буквы следует включать в языковые настройки, если они встречаются в заимствованных словах. Дополняя то, что сказал anon848905, я работал на языке, где «b» встречалась только в заимствованных словах, глоттальная b (b’) и «v» встречались в исконных словах, и было обычным делом забыть набрать глоттальную или перепутать «b» с «v».
После включения "b’ ", «b» и «v» как законных символов очень полезным способом находить неправильные слова было использование команды «Найти похожие слова» (Find similar words) в Списке слов. Включив пары этих трех звуков в поле «Буквы, звучащие похоже» (Letters that sound alike), Список слов выводил пары слов, различающиеся только этими звуками. (Например, если в переводе встречались и «bolt», и «volt», сравнение «b» и «v» вывело бы эти два слова и показало, сколько раз каждое из них встречается.)
Кроме того, просмотр Списка слов, чтобы увидеть слова, встречающиеся в переводе, помогал находить слова с ошибками в написании — будь то из-за букв из заимствованных слов или из-за того, что несовершенные люди случайно допускали ошибки.

Переведено машиной с языка English Показать оригинал

Answer 4

Разве не должно быть способа пометить иностранное слово с помощью SFM? Кажется, что иногда в наших переводах мы хотим включить французское слово, чтобы объяснить что-то в сноске, но было бы хорошо выделить его с помощью SFM, и в идеале, чтобы инвентарь символов Paratext не включал слова, помеченные таким образом. SFM, помеченные таким образом, не обязательно должны набираться по-другому, если это не требуется.

Переведено машиной с языка English Показать оригинал

Comments

Да, мы делали то же самое – используя LWC в сносках – и нам нужно было специально пометить эти символы как допустимые (Valid). SFM для их пометки, я полагаю, помогли бы при выборе подходящего шрифта на этапе набора.

Переведено машиной с языка English Показать оригинал

Answer 5

Я нашел маркер \tl … \tl* в справочнике USFM:
http://ubs-icap.org/chm/usfm/2.4/special_text_character_styles.htm#tl
(Возможно, вам придется щелкнуть по ссылке \tl … \tl*, чтобы перейти к объяснению этого конкретного SFM…)

Он определяется как:

Транслитерированное (или иностранное) слово(а).

Этот SFM может использоваться (как в примере, приведенном на этой странице) для слов, которые вы хотите видеть по-другому (например, курсивом) при наборе. Но они не обязательно должны выглядеть по-другому. Я могу представить, что мы захотим использовать этот SFM в сноске, где есть слово(а) как часть объяснения на французском языке, но то, будет ли оно набрано по-другому или нет, — это вопрос для команды. Но если мы пометим эти иностранные слова, возможно, их можно будет исключить из инвентаря символов.

Я протестировал инвентарь символов, и он ВСЕГДА включает символы, находящиеся внутри маркера \tl … \tl*. Мне кажется, что если это транслитерированное и/или иностранное слово(а), возможно, текст должен быть исключен из инвентаря символов. Или, может быть, лучше добавить флажок под флажком «Показывать комбинации» (Show combinations) с названием «Включать иностранные слова (\tl)», и когда этот флажок снят, текст, помеченный \tl, исключается. Звучит как довольно простой и очень полезный запрос на функцию, @anon291708?

Переведено машиной с языка English Показать оригинал

Comments

jeffh:

Звучит как довольно простой и очень полезный запрос на функцию, @anon291708?

Да, фильтрация символов в определенных стилях в Проверке/Инвентаре символов (Characters Check/Inventory) была бы простой задачей.

Переведено машиной с языка English Показать оригинал

Answer 6

Я думаю, что здесь рассматриваются две разные проблемы. Первая — это пометка иностранных слов и возможность с ними работать. Это уже существует. Вторая проблема — должны ли эти символы перечисляться в инвентаре символов. По моему мнению — любой символ, который будет напечатан, должен быть перечислен в инвентаре символов, чтобы вы могли проверить, являются ли эти символы допустимыми или нет. В языковых настройках (Language Settings) вы указываете символы, которые принадлежат языку, но вам действительно нужно иметь возможность определить, есть ли у вас другие символы, которые будут напечатаны. Мне неясно, что будет получено, если опционально скрывать эти символы из инвентаря. Когда вы помечаете символы как допустимые в Инвентаре символов, вы не говорите, что это символы языка, а то, что они являются допустимыми символами для печати в этом проекте.

Переведено машиной с языка English Показать оригинал

Comments

Я работаю в проекте, где есть ряд пользовательских маркеров (\zeng, \zgrk, \zheb и т. д.) для пометки разных языков. Это позволяет нам использовать разные шрифты и направления письма для разных языков. Но дополнительным преимуществом было то, что пометка их как \nonpublishable в стиле (stylesheet) предотвращает их появление в инвентаре символов и, что более важно, в словаре для проверки орфографии (spelling wordlist).

Конечно, как комментировали выше, вы теряете некоторую функциональность, и в конечном итоге вы действительно хотите проверить, что все символы допустимы, поэтому я время от времени удаляю этот тег \nonpublishable, чтобы запустить проверку. И, очевидно, вы захотите удалить его, если ваша система публикации читает этот тег.

Переведено машиной с языка English Показать оригинал

---

Основная проблема здесь в том, что мы работаем в многоязычном мире (греческий, иврит, местный язык, язык широкого общения), но редактор в Paratext этого не распознает. Поэтому «все» в проекте X находится на языке X. И такой подход слишком упрощен.

Нужен способ пометить греческий, иврит и язык широкого общения (LWC) с помощью уникальных стилей SFM (для каждого) и поддерживать их отдельно в списке «Допустимые/Недопустимые» (Valid/Invalid). И НЕ смешивать их с инвентарями символов, орфографии или списка слов языка X. (Даже допустимая пунктуация LWC может быть недопустимой для языка X.)

Там, где мы работаем, сегодня мы можем пометить как допустимую странную букву, найденную в слове из LWC в сноске. Но открывает ли это возможность того, что кто-то может ввести опечатку на языке X, используя этот «допустимый» символ, потому что мы пометили его как допустимый? То есть он допустим для LWC, но НЕДОПУСТИМ, если используется на языке X.

Так как же мы это различаем? И почему мы не можем просто пометить их как разные языки? Это кажется самым очевидным решением. Каждый другой достаточно мощный редактор, который я знаю, распознает «язык», и, конечно, мы должны делать это в нашем деле перевода.

Допустим, это не нужно очень часто, но это нужно достаточно часто, чтобы решение было бы очень полезным. (И я согласен с anon848905 в том, что просто «игнорировать» их — не идеальное решение.) Они «допустимы» в определенных случаях; нам нужно, чтобы Paratext был достаточно умным, чтобы распознавать контекст (скобки SFM) и валидировать их на основе их конкретного подмножества.

Переведено машиной с языка English Показать оригинал