Maybe I should explain. Currently the code caches the dig sites, which presents the obvious problem with Blizzard adding/removing/changing them. Archy uses Astrolabe-1.0 to calculate position and distance to the dig sites relative to the player's current position.
The caching makes me puke. And yes, I plan on doing a complete rewrite, but in the meantime, the 4.1 sites are causing all sorts of errors, from untranslated strings to just not point the player properly and everything in between.
LibBabble-* libraries are for string translations, not for generic data. If you want to track positions, distances, etc. -- anything other than simply mapping the English name of something to the localized name of something -- your library should not be named "Babble". Call it "LibDigSiteData-1.0" or something.
Fair enough. Just so I understand correctly, if I limit the scope to translating the dig site strings, for example "East Auchindoun Digsite", then it is OK to use "Babble", but leave the position, distance, etc to something else? That would work for me, as it is all I really need.
And that is exactly what I have done. Just the names, ma'am. I do have one question, after reading the existing *Babble-* files, regarding how the localization system works for them. Unlike Nev, ckknight, and Ackis, I am not running a script. Therefore, before I muddle this up, I was wondering if the following code will work with the wowace system: paste. You might notice I am combing esMX into esES, but I am concerned about the whole thing.
As an interesting note, the keyword substitutions work great for a "live" version, but don't work for a development copy. I will have to extract the tables from the localization app and hard copy/paste them into the lib.
... Unless someone has a bright idea why the --@localization()@ isn't doing its thing with dev copies?
Because the server makes the changes not your SVN software. Even if it did, the changes are made post-commit and are not made to local copies. There's a reason for this. For example: "@project-version@": You'd have to remember to change the version back to this every time you commit which would defeat the purpose.
Personally I'm using a PHP script that extract the strings from my sources, upload them to the localization system and then update the Localization.lua file with every defined locales. It reads the wowace API key from $HOME/.wowaceApiKey to access the website.