New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(Scripts/Spells): Hardcoded text moved to database to support loca… #18757
base: master
Are you sure you want to change the base?
Conversation
The data in the broadcast_text and broadcast_text_locale is sniffed and cannot be modified under normal circumstances |
I saw that in the code style after commit. I'll take another look at this today, thanks. |
So the issue I am facing now is that using the broadcast_text unmodified duplicates the player/caster name: %s plants the Flag of Ownership in the corpse of $n. %s is the player name, and outside of the broadcast text it is also printed, so the result is: PlayerName PlayerName plants the Flag of Ownership in the corpse of TargetName. This is what initially led me to my original solution of modifying that text before I knew about the limitations of updating that table. |
Perhaps something other than |
I have a working solution local that does the same thing I did with the $n placeholder. However, I am not sure if this is the best approach. I can commit and have this ready for review unless someone else has any suggestions for alternatives to |
…lization
Changes Proposed:
This PR proposes changes to:
Issues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
This is how I tested the changes:
Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.