If people are sick of the wording 'jumpshot' and they change it to 'jumper'.....then eventually people will just get sick of the word jumper.
The idea is not to simply reword, the idea is to leave the wordings that are there, there, but to add OTHER wordings AS WELL to add flavor and variety. The idea is that we want more variety/play types etc...
We aren't gonna get a new GE with new types of events, so they would need to make different wordings for the same types of events so that they seem different. I think there is already several kinds of events that can just be worded differently in the viewer...
So what we ARE asking for (I think atleast) is a game viewer update, which could only be done by the BBs, where they actually add new texts. If this were done, all the LAs would get new tags in their queue to translate. I was an LA for several seasons and personally finished the Japanese translation (although I did not do the bulk of the work, I did a few thousand tags at the end so that finally the game could be released in japanese)...
Anyway The point is I know what I am talking about and Will obviously does not.
I guess the question I had based on how I interpreted what you read was whether the base American English version also had the text pulled from tagged resources like other localized languages or whether it was hardcoded. We have done some localization on the software product I work on and initially there were a lot of hardcoded strings in the program that we'd just say "If they're Spanish, do this instead." That quickly proved to be dumb and now we have a localization setup with keys for English-US, English-UK and Spanish and it's possible that if we expand to other markets that we could translate quite quickly. So pretty much all of my post was more just curiosity on that front.
Having multiple texts for the same event key would probably also be doable, and I'd agree that would be a nice implementation. If I take a hypothetical key like MIDRANGE_JS_BAD_MISS, for example, just adding five or ten versions like MIDRANGE_JS_BAD_MISS_1, etc. would solve the problem pretty cleanly - and when the calculation occurs that creates the key for viewer/pbp, it can select one of those 10 at random or even just by using a specific digit from the previous generated random number. But, yes, that would definitely require BB intervention and the usual caveat about development priorities and whatnot clearly are in effect.