Scripture Reference Settings doesn't seem to obey character normalization setting

Question

I've been helping to troubleshoot a project where the Scripture Reference Settings (Paramètres de références bibliques) has flagged multiple conflicts between the book names as defined in the settings and those used in the text. The project is set to use NFD normalization. It turns out that at least some of the conflicts are due to mixed character types in the Settings (e.g. sometimes â [\u00e2] is used, and sometimes â [\u0061\u0302]). It would be great if the text entered into this settings window (or maybe it's limited to only the Book names tab?) was auto-normalized according to the character normalization setting.

Also, a complete side note, but somehow a couple of these book names ended up having zero-width, non-breaking spaces [\ufeff] at the beginning of the string, too. I have no idea how that would happen.

Answer 1

Please report bugs or make suggestions for changes to Paratext using the Give Feedback feature of Paratext. The developers often review these questions, but there is no guarantee that something suggested in this site will be added to the support queue.

In the meantime, if you know that Paratext is normalizing the text, and the two conflicting entries look the same, then you should be able to select the text option and approve it.

As to the question of the zero-width, non-breaking spaces - does the team use any AutoCorrect that might insert those? Or could the be copied from some other location?

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?