A new 'hyw' language code has been registered for Western Armenian,
and the arevela and arevmda variant subtags have been deprecated.
This still accepts the hy-arevela and hy-arevmda language tags, but
uses the preferred names for the language files.
E.g. for 'port' this goes through following transformations:
1. written 'port' to phonetic [p'o*@-tS] for eSpeak NG
2. espeak [*] was mapped to MBROLA [r] and [@-] was just skipped
resulting [rt] which is not allowed diphone in br1 voice.
Description of fix:
mapping phonetic [*@-] to [r2] (and skipping [@-]) makes [r2-...] which is
in diphone database. That fixed warnings:
mbrola: Warning: r-t unkown, replaced with _-_
mbrola: Warning: r-d unkown, replaced with _-_
mbrola: Warning: r-n unkown, replaced with _-_
mbrola: Warning: r-m unkown, replaced with _-_
mbrola: Warning: r-s unkown, replaced with _-_
It is possible -- especially at higher speeds -- for the n at the
end of a word to be velarised if the next word starts with a velar
plosive. I prefer the velarised sound between word boundaries, but
others do not. As such, limit the velarisation to within the word
only.
[1] https://en.wikipedia.org/wiki/English_phonology
Revert "maintainability: pass seq_len_adjust to LookupSpect() instead of using globals"
This reverts commit d08b8e43ca.
This commit causes gcc-4.8 to output a different SHA1 hash on the
language-phonemes test for `af` (the first language tested). It
does not break on clang or on gcc-7 so may be a compiler bug,
however the Travis CI build server is using it on Ubuntu Trusty
(14.04 LTS) and so may other older OSes.
LookupDict2: Fix searching entries longer than 128
This is a fix for https://github.com/nvaccess/nvda/issues/7740.
With the addition of emoji support, dictionary entries can now be
longer than 128 bytes. This fix makes sure the character is
interpreted as an unsigned byte so it does not treat long entries
as having a negative offset.
Treating the offset as a signed byte (like in the previous code)
could cause the hash chain search to loop indefinitely when
processing certain input, like the Tamil characters in the NVDA
issue noted above that is added as a test case to translate.test.