Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Why not just ninja the blizzard format strings? and deformat them
That's not so simple as it appears... I think it's Blizzard still didn't finish the work yet (Reinforcements counters are still bugged for example... and this is already an official release).
Let's take a simple example (I will give translit version so everyone can see it):
"Na Zapadnuyu Bashnyu Severnogo Volka napali! blablabla" - here is the name of the tower NOT in nameing case so when the horde defends it, we will have "Zapadnaya Bashnya Severnogo Volka blablabla" which is in nameing case. The problem is that the addon uses found name as an ID for the counter bar. So it will create a bar with ID "Zapadnuyu Bashnyu Severnogo Volka" but when horde defends it, addon will try to stop the bar with an ID "Zapadnaya Bashnya Severnogo Volka" and there is no such ID as you can guess, and we will have wrong timer bars...
I can see a way to fix it in creating more variables for locale. Also we'll have to separate the strings that we're catching from the messages and the ones that we're displaying at the bars, so more variables again... We can edit addon functions so it can work with our locale, but then we'll have to edit every locale translation for other languages which makes the localization process too complicated for just "localization" I guess...
P.S. Can you tell me where to ninja exact Blizzard strings exepting the manual looking in-game?
Hello again. I found a way to handle AV problem with russian client. Also this will allow to use custom labels for bars instead of fixed names that have been captured from messages.
But it will require to fill little table in every localization file (excepting ru and en because I did it). I've inserted templete to every locale file that has to be edited.
Everything works for me here and ready for commit, but I just want ot ask the permission to do so, as it will require additional localization work before it will be able to work for all clients.
If it breaks the localization for other clients, you should not commit. It also sounds like a big change that I may need to check out first.
Again, if RU localization brings too many complications, I suggest just making a dedicated RU version of Capping. You have my permission to do that, and you may call it whatever you want.
It's not hugr changes, it's just a little additional table in localization file and acouple lines changed in the code.
Please, tell me where can I post it for you, so you can check it?
Since it will break the mod for other clients, I won't allow this change. I don't have dedicated localizers for Capping; it's whoever-whenever. Therefore I really suggest that you make a dedicated version.
OK. No is no.
I'll make dedicated version as soon as I'll find a way to fix wsg flag keeper name for the horde side as it appears in log not in naming case.
Your addon works with russian client atm but with these: limitations:
- Timers will not be stopped for some AV towers/GYs when they are defended.
- Labels at those timers are not in naming case so they're looks like spoken by foreign languager ;)
- Nickname of the player that picked up the Alliance flag is not in naming case so it's colored white and don't targeting the player if clicked.
By now, I'll enjoy the fact that I am the only one at RU servers, who got 100% working AV timers ;)
I found a way. There's not documented API function that can decline names... I just found out that I have a problem with comparing same strings in UTF-8 is not always true... it's wierd, but I'm gonna find out why.
Well, the question is... Can you suggest a name for RU dedicated addon? I was about to name it Capping_ru, but I guess people will not understand that they have to install it separately. They will think that it's an addition for original capping or something. In other hand... naming it completely different will be not very good to you.
That name is fine (maybe Capping in Russian could work). Make sure the notes mention that this is the Russian version; also probably add a locale check/break at the beginning of the file like I did for all the localizations just in case.
[2008/10/13 11:32:36-122-x1]: Capping-2.4.011\core.lua:222: attempt to call method 'SetTextFontObject' (a nil value)
Capping-2.4.011\core.lua:112: in function <Interface\AddOns\Capping\core.lua:111>
Was able to get rid of it by replacing "SetTextFontObject" on line 222 with "SetNormalFontObject". The former API call was removed and replaced with the latter.
Just want to say that I moved all of my addons to www.wowinterface.com under the same username (totalpackage). I'm using the SVN they have there, which is great. If you would like permissions to edit my projects, just send me a private message over at wowi. Thanks.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
That's not so simple as it appears... I think it's Blizzard still didn't finish the work yet (Reinforcements counters are still bugged for example... and this is already an official release).
Let's take a simple example (I will give translit version so everyone can see it):
"Na Zapadnuyu Bashnyu Severnogo Volka napali! blablabla" - here is the name of the tower NOT in nameing case so when the horde defends it, we will have "Zapadnaya Bashnya Severnogo Volka blablabla" which is in nameing case. The problem is that the addon uses found name as an ID for the counter bar. So it will create a bar with ID "Zapadnuyu Bashnyu Severnogo Volka" but when horde defends it, addon will try to stop the bar with an ID "Zapadnaya Bashnya Severnogo Volka" and there is no such ID as you can guess, and we will have wrong timer bars...
I can see a way to fix it in creating more variables for locale. Also we'll have to separate the strings that we're catching from the messages and the ones that we're displaying at the bars, so more variables again... We can edit addon functions so it can work with our locale, but then we'll have to edit every locale translation for other languages which makes the localization process too complicated for just "localization" I guess...
P.S. Can you tell me where to ninja exact Blizzard strings exepting the manual looking in-game?
But it will require to fill little table in every localization file (excepting ru and en because I did it). I've inserted templete to every locale file that has to be edited.
Everything works for me here and ready for commit, but I just want ot ask the permission to do so, as it will require additional localization work before it will be able to work for all clients.
Thank you. Waiting for an answer.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAgain, if RU localization brings too many complications, I suggest just making a dedicated RU version of Capping. You have my permission to do that, and you may call it whatever you want.
Please, tell me where can I post it for you, so you can check it?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI've made "-- NEWCHANGESHERE" mark for you everywhere I made changes, so you can easly find it.
Same new table are in every other locale file, but I'll attach only ruRU one here.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'll make dedicated version as soon as I'll find a way to fix wsg flag keeper name for the horde side as it appears in log not in naming case.
Your addon works with russian client atm but with these: limitations:
- Timers will not be stopped for some AV towers/GYs when they are defended.
- Labels at those timers are not in naming case so they're looks like spoken by foreign languager ;)
- Nickname of the player that picked up the Alliance flag is not in naming case so it's colored white and don't targeting the player if clicked.
By now, I'll enjoy the fact that I am the only one at RU servers, who got 100% working AV timers ;)
Well, the question is... Can you suggest a name for RU dedicated addon? I was about to name it Capping_ru, but I guess people will not understand that they have to install it separately. They will think that it's an addition for original capping or something. In other hand... naming it completely different will be not very good to you.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWas able to get rid of it by replacing "SetTextFontObject" on line 222 with "SetNormalFontObject". The former API call was removed and replaced with the latter.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium