Changing Normalization on existing project

Question

I am an administrator for several translation projects which need to change their normalization settings from None to Decomposed. This is to allow the proper handling of symbols like á, which we would like to stay as decomposed characters, because of the keyman keyboard we use for any work done outside of Paratext. The help files suggest that the only way to change the normalization is to use the Covert Project feature.

However, in version 8.0.100.71, Paratext now allows me to change the normalization directly without conversion. Was this changed in a recent version? Should the help files be updated to reflect this?

Thank you.

Answer 1

Yes Stephen+Katt. This is a recent improvement (Aug 2018) which obviously hasn’t been updated in the Help files yet. Thanks for pointing out the inconsistency.

Answer 2

Mark+P:

This is a recent improvement

Thank you for the update. This change should make things much easier for us.

Comments

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/