Настройки ссылок на Писание, похоже, не соблюдают настройку нормализации символов

Question

Я помогал устранять неполадки в проекте, где Настройки ссылок на Писание (Paramètres de références bibliques) выявили несколько конфликтов между названиями книг, заданными в настройках, и теми, что используются в тексте. В проекте установлена нормализация NFD. Оказалось, что по крайней мере часть конфликтов вызвана смешением типов символов в настройках (например, иногда используется â [\u00e2], а иногда â [\u0061\u0302]). Было бы здорово, если бы текст, вводимый в это окно настроек (или, может быть, это ограничено только вкладкой «Названия книг»?), автоматически нормализовался в соответствии с настройкой нормализации символов.

Кстати, совершенно в стороне, но по какой-то причине у пары этих названий книг в начале строки оказались неразрывные пробелы нулевой ширины [\ufeff]. Я не имею понятия, как это могло произойти.

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

Answer 1

Пожалуйста, сообщайте об ошибках или предлагайте изменения в Paratext, используя функцию «Дать обратную связь» (Give Feedback) в Paratext. Разработчики часто просматривают эти вопросы, но нет гарантии, что то, что предложено на этом сайте, будет добавлено в очередь поддержки.

Пока что, если вы знаете, что Paratext нормализует текст, и два конфликтующих записи выглядят одинаково, то вы должны иметь возможность выбрать вариант текста и утвердить его.

Что касается вопроса о неразрывных пробелах нулевой ширины — использует ли команда какой-либо автозамен (AutoCorrect), который мог бы вставлять их? Или они могли быть скопированы из какого-то другого места?

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

Comments

Thanks for the reminder to use the "Give Feedback" feature. But what if other users have the same problem or suggestion or feedback? They aren't able to see feedback that has already been given this way and are unaware of what has been tried, or if there are any workarounds, or even if the idea has been considered and will later be implemented or discarded.

Yes, you're right about probably being able to just overwrite the settings with the actual text in the case of the mismatched character encoding. But I couldn't be sure that that was the only source of the conflicts. What if there were other "hidden" \uFEFFs, but in the text instead of the settings? I ended up checking out the unicode representation of each settings string in a different program and making sure the correct characters were used.

I can't answer the question about the source of the zero-width, non-breaking space. I doubt they are using AutoCorrect, but I can find out. My initial assumption was that it was introduced somehow by copy/pasting text, but I still don't know where they would have copied the text from other than Paratext itself. Maybe a Word document a long time ago (>10-15 years), if initial drafting was done that way?