WowAce

What is the enhancement in mind? How should it look and feel?

Similar to the <Third Person|me> feature, I would like to have a feature to use <Second Person|you> when whispering to someone.

Please provide any additional information below.

The intended application of this feature is to modify a public announcement:
I put a shield on <target>!

So that it sounds more natural as it is simultaneously whispered to the target, saying:
I put a shield on <you>!

I misnamed this feature but I don't know what else to call it... Technically using the name is third person, and you is second person, and the "|" is read "or" from programming languages, so it's really a third person or second person toggle that should be called <third person|you> but that's also a bad name for this idea because technically the parser treats that exactly the same as <third person|me> so... whatever, not important... LOL

The nature of the parse is going to want to treat <target|you> as a third-person or "me" check if using the same character, but I wonder if that's OK from the sense of string parsing, and we could do this in the implementation of whether or not we select the pronoun ... i.e. treat it as an expansion of <third person|me> to <third person|pronoun> and enhance the logic to be more general about detecting when the pronoun should be used.

Currently in 3.2.2.10, the logic simply decides that if the substitution value for ANY <subtitution> == UnitName("player") then use the pronoun.

The target of a whisper appears to be a special case which could accept fairly simple additional handling to detect if you are performing the "[X] Whisper <target>" function then go back and replace <target> with the pronoun.

I am hesitant about whether this is really an isolated special case, or part of an even bigger issue... Are there other cases where you want to use a pronoun other than:

A) first person pronouns: already supported in 3.2.2.10 to avoid naming yourself in the third person, for any possible substitution using <target|me>

B) gender pronouns: already supported in 3.2.2.10 for any substitution who's gender can be determined, using <target*him*her>

C) second person pronouns: the topic of this ticket

This applies to "[X] Whisper <target>"

If you write"/t <target> I cast a spell on you" then you don't need parsing logic to substitute the pronoun for you in an automated "smart" way

Channel = Reply is another whisper feature (see ticket 64) but then you know your targets are whispers, so again you don't need support for smart parsing/substitution forms in "Thanks for the buff, <caster|you>" You can just say "/t <caster> thank YOU!"

I'm not seeing other cases, so i guess we can start with a simplistic solution that treats this as a special case, just for <target> in a "whisper target" scenario, and build on it later. But if ideas come to light related to this before I start on it, that may help plan the implementation for growth.

I like the idea of redefining the nature of <third person|me> as a more general <third person|pronoun> ... just calling that and renaming some variables would make the code/logic more sensible than having variables called "me"

Note there is a functioning work-around for this in 3.2.2.10

Disable the [ ] Whisper Target feature

write the speech with 2 lines:

I put a shield on <Target>| /t <target> I put a shield on YOU!

giving this a low priority given the flexibility and power of the work-around and uncertainty about the full extent of pronoun issues.

Here is some refreshed thinking on this ticket, inspired by the new (duplicate) ticket 131

The current version is 3.3.5.10

-----

SYNTAX:

This should be implemented as <target@you>.

@ seems like an appropriate delimiter to mark a pronoun for your target, in a way that builds on the existing (v3.3.5.10 pronoun forms.

The complete support would be this:

<target|me@you*male*female>

It's a bit nonsensical to mix gender and second-person forms, but if this were for an event that could target both players and NPCs or mobs, it's reasonable you could cast on yourself, one person to whom you whisper, or an NPC that you'd refer to by gender.

So first and second person pronouns would take precedence over (third person) gender pronouns.

---

ACTIVATION:

The second-person form would be used under these 3 conditions:

1) When whispering to the <target> because of the checkbox feature.
- only applicable when <unit> is <target>

2) When whispering to the <unit> because that line of the speech starts with "/t <unit>" or "/w <unit>" or equivalent localized prefixes.
- <unit> can be any unit in this case, for example to congratulate a guild member on an achievement, one might use "/t <caster> something about <caster@you>"

3) When the <unit> is the only other member of the chat channel.
- applies to guild, raid, party, and battleground.
- You're speaking in an open chat channel instead of a whisper, but if there's only one other person there, you're speaking directly to that person, and in such a situation IRL, you'd typically use a second-person pronoun instead of their name.

For example using the speech "I'm battle-rezzing <target@you>!" makes sense in the raid channel if you're 2-manning an old-world raid.

Updated the title to reflect my current thinking.

Hum. I guess localization could possibly add to this issue. As I'm a german player, playing on a german server, the current posessive pronoun feature is of little use for me (as german posessive pronouns are created differently).

That's one reason why I think you might be right saying this might be only a part of a bigger issue. I'd love to see some more options in this, but currently have no idea what (or how) you might add it.

Guess I'll think about it a while. Maybe expanding the <randomsubstitution> feature to offer various kinds of conditionals would be a way to solve this? I already thought about asking for something like this. I love creating Macros within WoW and make heavy use of macro options. I think something similar for SpeakinSpell would be cool.

I'm re-assigning all my tickets to Duerma

Unassigning tickets that are not actively being worked on