LibKarma

LibKarmaAce

Simple integrated automated lightweight support for other basic desparate libraries and systems

Notes

This is primarily a way to hobble together rock, ace2, ace3, minimap, fubar, ldb, titan, and others in a way where the addon can be blissfully unaware. Either rely on any or none of these facilities being available and get at worst case a native minimap icon with a right-click menu.

Table structures (yes confusing):

1. LibKarmaAce -- global lib section instance
2. ..._acelib -- global lib section data (aka _instG)
3. ...[funcs] -- global lib section functions
4. LibKarma -- global lib section instance
5. ...[funcs] -- global lib section functions
6. inst -- addon intance of LibKarma (inherits LibKarma and LibKarmaUtil)
7. ..._acelib -- instance Ace lib section data (inherits LibKarmaAce._acelib) (aka _inst)
8. ......instance -- ace3 instance or stub table (aka _inst.instance). this lowers the chance of name conflicts rather than using _acelib (_inst)
9. ........._karma -- reference back to inst, so that ace3 funcs can find home, the karma lib instance table
10. .........[funcs] -- added selective LibKarmaAce lib section functions

Locale System

Notes on the locale integration

Yes, the locale system does load all the reverse lookup tables for all available locale libraries. The reason is that all strings for the current locale and for english are already taking memory for all the locale libraries (and for the current locale even if the locale libs didnt exist), and its by far more effiecnt to just keep the reverse lookup tables which only hold string references anyway. Some applications are hitting the reverse lookup constantly and necessarily, up to 100s of times a frame, and allows a very fast non-memory churn way of doign this. Also this allows features which are faster here, closer to the metal, than emulating and separatly tracking them per app or use, and for the integration of multiple lib and app locale systems with one call.

This is very little code all the way around for what you get, and far less code on the use side. Only the final locale system collection is per instance, the rest of the tables and management is global. Some forms up lookups are regretibly wrapped and stuck on the Lua side, but watching the meters its really about as tight as you could expect and still very fast.

Lib issue awareness and mitigation

Yes for each lib a reference is held that theroetically should be transient per use. In practice for normal applications the non babble instances usually have a local refernce held per file anyway which will lock that app to its data generated by the latest version loaded at the time the file was run, and... its holding a reference to the table. This library initalizes locale by design after all addons libs have loaded and checks attempts load on demand for what left, before holding a reference, which should guarentee a reference to the latest version. Apps that use this library also will by design be guarenteed coherency at player_login and any event there after, if they use a libkarma instance for event management, or if they follow the pattern in libkarma by initalizing addon_loaded step and player_login step on each event before their own code. LibStub holds references as well for all other libs including babble. Its far more efficent to have a reference to some parts of the lookup chain rather than asking LibStub over and over.

Lookups in the lookup collection by default

1. the addon's AceLocale instance, if it has one
2. this libraries locale instance, which includes this libraries locale info and can be use by the addon for its own, as alternative to AceLocale. This locale bag can be altered at anytime and is not frozen after load like AceLocale.
3. a string capture bag for lookup misses, which allows the rest of the tables to no longer have to be lookup. if enabled by changing a setting in the .toc file of the addon which is expressly for capturing untranslated strings by anyone who wishes to provide translations, then these strings are saved in the addons settings file for use
4. a set of library provided lookups, such as babble libs

Features

1. Two forms of lookup are provided L and LR, normal and reverse, and each is a drop in replacement for AceLocale style lookups. i.e. L["mystring"] LR["myspanishstring"]
2. L and LR both automatically do lookups across the locale collection
3. L and LR will not generate errors on misses, a miss will place the result in the instance capture bag.
4. L and LR will strip color wrappers automatically i.e. "|cFFFFFFFFmystring|r" and lookup up "mystring" and return "|cFFFFFFFFmyspanishstring|r"
5. L and LR both have F member that will lookup a formated string and replace format elements. i.e. local dispstr = L:F("My number %d and name %s", 33, "Yumesyoukai"); or more usually: L"MYNAMEANDSTRING"] = "My number %d and name %s"; local dispstr = L:F("MYNAMEANDSTRING", 33, "Yumesyoukai"); Special care should be taken of course in doing formatted reverse lookups.
6. L has two members for convienence S and R. S is a short cut to do a lookup on just the addons AceLocale instance i.e. L:S["myaddonspecificstring"]. R is a shorcut to LR so that you only have to get L to use LR i.e. L:R["myspanishstring"] is the same is LR["myspanishstring"]
7. attempting L["mystring"] = "myspanishstring" will place the result in the instance capture bag and can be done anytime, including effectivly overriding an existing translation without error.
8. adding translations feature allows an addon to dynamically add translations and provides more flexbility as to where and when this happenes. but also allows an addon to override any karmalib wording and messages, or any other depandancy. karmalib will use the same instance L and LR for lookups as the addon. is far easier to relable a menu item this way then makign a new menu or hacking the exsiting one
9. all instance capture elements will override all other translations