Develop multi ling 03 10 2019 no mb4 pg

[mgage]

tweak encode(UTF-8) and :utf8 layers for input/output. This version should work with legacy courses and versions of mysql older than 5.3 which cannot handle utf8mb4. This replaces PR #390

[taniwallach]

I have not yet had a chance to test the code in this new PR for multi lingual support.

However:

1. It is not clear to me how the pg code as compared to what was in New develop candidate multilingual #390 has any direct relation to the SQL level difference between utf8mb4 and utf8.
   • The mySQL utf8 charset is a subset of the full UTF8 which includes only characters which need at most 3 bytes in the UTF-8 encoding, and excludes those which use the fourth bytes. As PG does not interact directly with the database - it should not have any direct relation to this issue.
   • Maybe this is just an error in the explanation given in the commit message for ead35d7
2. The changed files relative to New develop candidate multilingual #390 seem to only be VERSION (minor change) and lib/PGloadfiles.pm (but some of PR 390 was changed by a very recent commit 3d94218 discussed more below, and a merge commit from develop of unrelated changes).
   • Maybe the problem was just that open(MACROFILE, "encoding(UTF-8)", $filePath) || die "Cannot open file: $filePath"; should have had <:encoding(UTF-8) and only had encoding(UTF-8) ???
   • However, if this subroutine is being run in WWSafe - then the revised code should work around the problems getting the Encode module to work inside WWSafe.
   • Note: New develop candidate multilingual #390 had a different line open(MACROFILE, "<:utf8", $filePath) || die "Cannot open file: $filePath"; until commit 3d94218 tried to change it (and that older version of PR 390 has been working well for me).

[mgage]

Perhaps the lack of the colon is why encode(UTF-8) didn't work, but I don't think so. I think it was a conflict with Safe. I was wondering if the PGloadmacros.pl was run before Safe was locked down -- but it appeared this was not the case.

What is there now should be approximately equivalent to <:utf8 but allows for some additional intervention if that turns out to be helpful. utf8::upgrade() for example seems to try to upgrade latin1 text to utf8. I'm not sure how reliable it is.