Thanks for this, it fixes the issue, but imo it produces an inconsistency and is not exactly the expected behavior:

Expected behavior:
The symbol should be read according with the chosen parameters, even when other > emojis are excluded.

1. If a replacement is not included for the emoji and other values are changed, and then emojis are excluded, the symbol is not read regardless of the symbols level, so the other parameters are aplied when emojis are included.
2. If the replacement has been changed, then it would be read even when emojis are excluded. and the parameters are applied too.

This is my opinion. Your feedback is appreciated.

Thanks

Thanks for this, it fixes the issue, but imo it produces an inconsistency and is not exactly the expected behavior:

Expected behavior:
The symbol should be read according with the chosen parameters, even when other > emojis are excluded.

1. If a replacement is not included for the emoji and other values are changed, and then emojis are excluded, the symbol is not read regardless of the symbols level, so the other parameters are applied when emojis are included.

This is true. However, it is not very trivial to fix this. IN short, it probably requires treating emoji dictionaries as separate dictionaries, and that requires a lot of work.

2. If the replacement has been changed, then it would be read even when emojis are excluded. and the parameters are applied too.

I agree that this is inconsistent. The erroneous part of this issue is fixed though. Let's leave #8931 open for now.

Many thanks. I think it's a good idea treat emojis in separate dictionaries, or in a general way, profile dictionaries for symbols. I could try to collaborate if needed, but I don't like to make things difficult to experiment devs like you, since sometimes devs may find easier to work yourself than review and discuss with other people.
Anyway, if needed and it could be useful, I would start to work on this.
Cheers

I created a branch that:

• When emojis are checked, saves changes to an emojis-lang.dic file, which is always loaded as a profiles symbols file.
• If an user (not a profile) symbol is added, that is, when emojis aren't checked, the symbol goes to user file, but if the symbols dialog is opened when emojis are checked, it will be saved as emoji.
  So, I think this is more consistent, but perhaps the remove button should be disabled for emojis even when they aren't checked in config.
  Also, this is a step to make possible to use different symbol dictionaries for different profiles with some changes.
  I will wait for your PR and when it's merged into master, if this is appropriate, I can follow creating a PR from
  https://github.com/nvdaes/nvda/tree/fixEmojiReplacement

Thanks

I created a branch that:

* When emojis are checked, saves changes to an emojis-lang.dic file, which is always loaded as a profiles symbols file.

Problem with this is that you do not know whether you're editing an emoji o regular symbol. We somehow need to save the source of a symbol to have an edited instance saved in the proper user dictionary.

leonardder commented

Problem with this is that you do not know whether you're editing an emoji o regular symbol. We somehow need to save the source of a symbol to have an edited instance saved in the proper user dictionary.

In _getSpeechSymbolsForLocale(locale):

This code is included:
emojis = SpeechSymbols()
if config.conf['speech']['includeCLDR']:
# Try to load CLDR data when processing is on.
# Load the data before loading other symbols,
# in order to allow translators to override them.
try:
builtin.load(os.path.join("locale", locale, "cldr.dic"),
allowComplexSymbols=False)
emojis = builtin

...
return builtin, user, profileSymbols, emojis

emojis takes the value of added emojis when they are checked in config. Anyway, I have thought about adding a checkbox or combo box to determine if a symbol should be added to user or profileSymbols, if profiles would be supported.
Not sure if this addresses the problem.

@michaelDCurran: This is now also reported in #8758 (comment)

I changed the base branch back to beta. It might make sense to have this workaround in 2018.4. We can leave out the changes file entry?