Yes, It is a recent improvement to give users access to normalization. We are in the process of writing a brief announcement to encourage users to Go to Project Properties and Settings and consider which setting is best for their projects. All projects migrated to Paratext 8 before the normalization check box was added have their normalization set to none. Any projects created after the update will have their normalization set to “composed”. It is an improvement that users no longer have to “convert” their projects to change the normalization, but we are just getting the word out on this improvement.
Stephen+Katt, it sounds like you know that decomposed is the normalization that is appropriate for your projects since in your area a decomposed keyboard is being used.
For those not so familiar with normalization, I just want to say that the problem that normalization is meant to address is that some characters can be represented in more that one way under the Unicode standard. While they look the same to you and I, to Paratext and other software they are considered different characters. This lack of consistency causes problems with searches, filters, and the ability of Paratext and other software to rendering the character consistently on the screen and in printouts. To put it more succinctly, it is the mixing of composed and decomposed that needs to be avoided. The good news is that, even if some members of a team enter a character as composed and others enter it as decomposed, Paratext will “normalize” it according to the setting in Project Properties and Settings.
The article referenced here discusses the issue with “mixed encoding”:
http://pt8.paratext.org/2018/01/04/migration-preparation-issues/
