Ref #1271

For the case when word is smaller than 4 characters, we should not look at
the 3rd or 4th character before checking the previous ones, otherwise
we'd at best read uninitialized data, at worse non-existing data.

Ref #853

TranslateWord2 uses phonemes in ph_list2. Apart from the breakable loops, it
may statically require up to 7 phonemes. Then TranslateClause always
uses 2 phonemes. We thus have to keep these margins along the loops to
avoid any overflow.

Fixes #1073 #1095

TranslateWord2 uses phonemes in ph_list2. Apart from the breakable loops, it
may statically require up to 7 phonemes. Then TranslateClause always
uses 2 phonemes. We thus have to keep these margins along the loops to
avoid any overflow.

Fixes #1073

TranslateWord2 uses phonemes in ph_list2. Apart from the breakable loops, it
may statically require up to 7 phonemes. Then TranslateClause always
uses 2 phonemes. We thus have to keep these margins along the loops to
avoid any overflow.

Fixes #1073

This reverts commit 433d219eca.

With bash, echo "a\nb" will not interpret \n, while with dash, echo will
interpret \n. bash's echo would need -e, but dash does not know that
option and just prints it.

We can however just put \n litteraly in the script, both bash and dash
will understand it.

With bash, echo "a\nb" will not interpret \n, while with dash, echo will
interpret \n. bash's echo would need -e, but dash does not know that
option and just prints it.

We can however just put \n litteraly in the script, both bash and dash
will understand it.

This reverts commit 223ff9c8ad.

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

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.

If the list file contains a text replacement to another
entry in the list file, e.g.:

	ripost     riposte $text
	riposte    rI#p0st

calling it from a prefix or suffix rule such as 'riposted'
causes word_out[0] to be NULL, as TranslateWord3 has the
information needed to perform the mapping. In this case,
no phonemes have been written in this loop and the phonemes
have been calculated, so don't override them.