Authors CurseForge

Why not just ninja the blizzard format strings? and deformat them

Quote from Saroz »

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?

I may have missed it but is there an auto release option in capping ? (only thing I miss from battlegroundfu)

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.

Thank you. Waiting for an answer.

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?

Ah, forgot about this feature here ;)

I'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.

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.

Capping produces this error on the PTR:

[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.