Kaelten and others (including myself) have been working on a generic cross-community library stub called "LibStub", which acts similarly to a slimmed-down, bare-bones AceLibrary.
I think this would be a grand opportunity to put the babble translations in a generic context.
I've come up with a preliminary prototype for this, LibBabble-Zone-3.0 which requires no dependencies, not even AceLocale or anything along those lines.
Current API:
local BZ = LibStub("LibBabble-Zone-3.0") -- or AceLibrary("LibBabble-Zone-3.0") or Joker("LibBabble-Zone-3.0")
assert(BZ["Durotar"] == "Durotar in the current locale")
assert(BZ.has["Durotar"]) -- whether the current locale has it
assert(BZ.hasBase["Durotar"]) -- whether it exists in English.
assert(BZ["Something that doesn't exist"] == "Something that doesn't exist") -- this errors
assert(not BZ.has["Something that doesn't exist"])
assert(not BZ.hasBase["Something that doesn't exist"])
assert(BZ.reverse["Durotar in the current locale"] == "Durotar")
assert(BZ.reverse["Something that doesn't exist"] == nil) -- no error
for word in BZ.reverse("Durotar") do -- this iterates over every reverse translation.
-- do something with word
end
for english, localized in BZ() do -- iterates over every translation
-- do something with english, localized
end
Edit: I changed this a few posts down
----
I'd like to know what people think, if they have any suggestions, etc.
Like stated on IRC I think Babble should take a PT3 approach, where by having a core addon for thinking and external addons for the actual localization. People would set externals to the core addon and choose what else they needed localization wise. I think this would cut down code replication without any negative effects. PT3 seems to do it successfully.
local BZ = LibStub("LibBabble-Zone-3.0") -- or AceLibrary("LibBabble-Zone-3.0") or Joker("LibBabble-Zone-3.0")
local BZL = BZ:GetLookupTable()
local BZR = BZ:GetReverseLookupTable()
assert(BZL["Durotar"] == "Durotar in the current locale")
assert(BZ:HasTranslation["Durotar"]) -- whether the current locale has it
assert(BZ:HasBaseTranslation["Durotar"]) -- whether it exists in English.
assert(BZL["Something that doesn't exist"] == "Something that doesn't exist") -- this errors
assert(not BZ:HasTranslation["Something that doesn't exist"])
assert(not BZ:HasBaseTranslation["Something that doesn't exist"])
assert(BZR["Durotar in the current locale"] == "Durotar")
assert(BZR["Something that doesn't exist"] == nil) -- no error
for word in BZR("Durotar") do -- this iterates over every reverse translation.
-- do something with word
end
for english, localized in BZ:Iterate() do -- iterates over every translation
-- do something with english, localized
end
:D ... now i understood about 40% of that code in what it actualy does.. but i have a few questions, and please correct me if im wrong..
-As it is now, Babble is a "Module" of AceLocal-2.0. Meaning that it has a dependancy to a parent addon that maintains it functional structure and babble is just a set of pre defined translation pairs.
-if i understand correctly, LibBabble-3.0 is merging these 2 aspects togeather where the functional structure is integrated into the predefined tables.
-What i am gathering here is that the functional aspect of AceLocal-2.0 (Providing a registration of a base and translation tables and look up) is now incredabley small that just having a lib that uses it in this context presented would provide that same ablity to the rest of the addon? or would the "LibLocal" still be required?
Basically, each Babble module, e.g. LibBabble-Zone-3.0, would have no dependencies, but share internal code with each other. Said code is actually not that large (about 100 lines or so).
Neither AceLibrary nor AceLocale-2.2 would be required.
ok so with (for example) LibBabbleZone present in an addon, it would provide local functionality for the rest of the addon outside of zone local info (Ofc if called and set properly by the addon), or would a seperate lib be required to do that?
Changed mostly on suggestions by pastamancer (who has yet to mance me up some pasta):
Current API:
local BZ = LibStub("LibBabble-Zone-3.0") -- or AceLibrary("LibBabble-Zone-3.0") or Joker("LibBabble-Zone-3.0")
local BZL = BZ:GetLookupTable()
local BZR = BZ:GetReverseLookupTable()
local BZ_has = BZ:GetUnstrictLookupTable()
local BZ_hasBase = BZ:GetBaseLookupTable()
assert(BZL["Durotar"] == "Durotar in the current locale")
assert(BZ_has["Durotar"] == "Durotar in the current locale") -- whether the current locale has it
assert(BZ_hasBase["Durotar"] == "Durotar") -- whether it exists in English.
assert(BZL["Something that doesn't exist"] == "Something that doesn't exist") -- this errors
assert(not BZ_has["Something that doesn't exist"])
assert(not BZ_hasBase["Something that doesn't exist"])
assert(BZR["Durotar in the current locale"] == "Durotar")
assert(BZR["Something that doesn't exist"] == nil) -- no error
for word in BZ:GetReverseIterator("Durotar") do -- this iterates over every reverse translation.
-- do something with word
end
for english, localized in BZ:Iterate() do -- iterates over every translation
-- do something with english, localized
end
I hope you are meshing it all into 1 pastey for readability's sake, since once this stuff goes live people will be wanting and using standalone versions of LibStub and LibBabbleCore.
so...
1. When library incompatabilitys occur, which they will, have fun dealing with that.
2. When librarys are updated you will need to update every addon instead of the script doing it.
3. Good luck with the bitching performance users when you loose the ability to easily profile addons.
so...
1. Library incompatibilities don't have to occur.*
2. When libraries need to update, no script should tamper with any addons.*
3. You can include the library usage with the addon just fine if thats what you want, but if you don't embed you don't _want_ to include it with the addon, because you can profile the library itself separately.
* I believe and have said so for a long time that the current way of using trunk versions of libraries isn't very good. Taggeth thy Libraries and use it by tag version. If there is a new library tag, the addon author will (or not) use it in its next release/tag of the addon (see what i did there?) and then you will have it on your disk. * Library incompatibilities don't occur when you don't break an API in a minor update, and update the major when you do (i.e., new tag).
In order to support the usage you are describing you would need something similar to MS's "side-by-side" dll approach - which lets you have N copies of a library running in private locations instead of 1 global one. Thats the only way I can see tags being realistic for use with libraries by multiple developers. In-place upgrading is not compatible with the "tags" mode of library usage.
Somewhat off-topic, though still dealing with future design of Babble:
Is there any hope in the future of separating localization libraries by their intended locales? It seems quite ridiculous to me that my computer (running enUS WoW) has to read through a gigantic file full of localizations just to end up returning true for anything passed in. I've posted about this before (specifically, asking why rawget is used in AceLocale, preventing the use of metatables to simplify enUS translation tables), but never got any meaningful response. It looks like it would be simple enough to allow this, or at the very least, separate each locale's data into individual files so that their removal can be automated without having to parse any code.
It has never made sense to me that the design of AceLocale/Babble forced all users to download all translations, despite the fact that most are unable (or at least unlikely) to switch locales. As an enUS user, I wouldn't even need Babble for anything at all, except that addons relying on Babble for localization choke and die without it. Partly this can be blamed on addon authors who don't want the complication of checking locales to see whether Babble is required, but it could easily be resolved within the library itself. Splitting translations into separate downloads by locale would allow users to get only what they need, giving us more control (at the cost of possible confusion for novice users). It just makes more sense design-wise, as it lightens the load on the user's computer quite a bit even if they use an EU client and switch between locales occasionally.
Of course, I could be missing something, in which case I'd very much like to know what it is...
It's mostly done this way out of ease, seeing as the libs are able to be embedded, they'd need to be fully self-contained.
Also, by having a flat list of what spells (let's say) are available in English, you can check if a spell exists, which is very useful if you're dealing with situations where you don't necessarily know what's being fed in.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think this would be a grand opportunity to put the babble translations in a generic context.
I've come up with a preliminary prototype for this, LibBabble-Zone-3.0 which requires no dependencies, not even AceLocale or anything along those lines.
Current API:
local BZ = LibStub("LibBabble-Zone-3.0") -- or AceLibrary("LibBabble-Zone-3.0") or Joker("LibBabble-Zone-3.0")
assert(BZ["Durotar"] == "Durotar in the current locale")
assert(BZ.has["Durotar"]) -- whether the current locale has it
assert(BZ.hasBase["Durotar"]) -- whether it exists in English.
assert(BZ["Something that doesn't exist"] == "Something that doesn't exist") -- this errors
assert(not BZ.has["Something that doesn't exist"])
assert(not BZ.hasBase["Something that doesn't exist"])
assert(BZ.reverse["Durotar in the current locale"] == "Durotar")
assert(BZ.reverse["Something that doesn't exist"] == nil) -- no error
for word in BZ.reverse("Durotar") do -- this iterates over every reverse translation.
-- do something with word
end
for english, localized in BZ() do -- iterates over every translation
-- do something with english, localized
end
Edit: I changed this a few posts down
----
I'd like to know what people think, if they have any suggestions, etc.
Code for LibBabble-Zone-3.0: http://pastebin.com/f69680fb8
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm still contemplating it, though, though it does have its upsides (lack of code duplication), it loses the whole lack of dependencies thing.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'd much rather take the extra step and do 'local ZONES = BZ.lookup; print ZONES["STORMWIND"]' if it means keeping a clean api.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI also made it more future-proof, doing what pastamanster suggested:
Code here: http://pastebin.com/m398f44c4
Current API:
local BZ = LibStub("LibBabble-Zone-3.0") -- or AceLibrary("LibBabble-Zone-3.0") or Joker("LibBabble-Zone-3.0")
local BZL = BZ:GetLookupTable()
local BZR = BZ:GetReverseLookupTable()
assert(BZL["Durotar"] == "Durotar in the current locale")
assert(BZ:HasTranslation["Durotar"]) -- whether the current locale has it
assert(BZ:HasBaseTranslation["Durotar"]) -- whether it exists in English.
assert(BZL["Something that doesn't exist"] == "Something that doesn't exist") -- this errors
assert(not BZ:HasTranslation["Something that doesn't exist"])
assert(not BZ:HasBaseTranslation["Something that doesn't exist"])
assert(BZR["Durotar in the current locale"] == "Durotar")
assert(BZR["Something that doesn't exist"] == nil) -- no error
for word in BZR("Durotar") do -- this iterates over every reverse translation.
-- do something with word
end
for english, localized in BZ:Iterate() do -- iterates over every translation
-- do something with english, localized
end
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-As it is now, Babble is a "Module" of AceLocal-2.0. Meaning that it has a dependancy to a parent addon that maintains it functional structure and babble is just a set of pre defined translation pairs.
-if i understand correctly, LibBabble-3.0 is merging these 2 aspects togeather where the functional structure is integrated into the predefined tables.
-What i am gathering here is that the functional aspect of AceLocal-2.0 (Providing a registration of a base and translation tables and look up) is now incredabley small that just having a lib that uses it in this context presented would provide that same ablity to the rest of the addon? or would the "LibLocal" still be required?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNeither AceLibrary nor AceLocale-2.2 would be required.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumChanged mostly on suggestions by pastamancer (who has yet to mance me up some pasta):
Current API:
local BZ = LibStub("LibBabble-Zone-3.0") -- or AceLibrary("LibBabble-Zone-3.0") or Joker("LibBabble-Zone-3.0")
local BZL = BZ:GetLookupTable()
local BZR = BZ:GetReverseLookupTable()
local BZ_has = BZ:GetUnstrictLookupTable()
local BZ_hasBase = BZ:GetBaseLookupTable()
assert(BZL["Durotar"] == "Durotar in the current locale")
assert(BZ_has["Durotar"] == "Durotar in the current locale") -- whether the current locale has it
assert(BZ_hasBase["Durotar"] == "Durotar") -- whether it exists in English.
assert(BZL["Something that doesn't exist"] == "Something that doesn't exist") -- this errors
assert(not BZ_has["Something that doesn't exist"])
assert(not BZ_hasBase["Something that doesn't exist"])
assert(BZR["Durotar in the current locale"] == "Durotar")
assert(BZR["Something that doesn't exist"] == nil) -- no error
for word in BZ:GetReverseIterator("Durotar") do -- this iterates over every reverse translation.
-- do something with word
end
for english, localized in BZ:Iterate() do -- iterates over every translation
-- do something with english, localized
end
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI don't agree with that, that means it removes the option to have libraries standalone, or renders them useless.
so?
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator1. When library incompatabilitys occur, which they will, have fun dealing with that.
2. When librarys are updated you will need to update every addon instead of the script doing it.
3. Good luck with the bitching performance users when you loose the ability to easily profile addons.
1. Library incompatibilities don't have to occur.*
2. When libraries need to update, no script should tamper with any addons.*
3. You can include the library usage with the addon just fine if thats what you want, but if you don't embed you don't _want_ to include it with the addon, because you can profile the library itself separately.
* I believe and have said so for a long time that the current way of using trunk versions of libraries isn't very good. Taggeth thy Libraries and use it by tag version. If there is a new library tag, the addon author will (or not) use it in its next release/tag of the addon (see what i did there?) and then you will have it on your disk.
* Library incompatibilities don't occur when you don't break an API in a minor update, and update the major when you do (i.e., new tag).
Edit: spelling :3
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIs there any hope in the future of separating localization libraries by their intended locales? It seems quite ridiculous to me that my computer (running enUS WoW) has to read through a gigantic file full of localizations just to end up returning true for anything passed in. I've posted about this before (specifically, asking why rawget is used in AceLocale, preventing the use of metatables to simplify enUS translation tables), but never got any meaningful response. It looks like it would be simple enough to allow this, or at the very least, separate each locale's data into individual files so that their removal can be automated without having to parse any code.
It has never made sense to me that the design of AceLocale/Babble forced all users to download all translations, despite the fact that most are unable (or at least unlikely) to switch locales. As an enUS user, I wouldn't even need Babble for anything at all, except that addons relying on Babble for localization choke and die without it. Partly this can be blamed on addon authors who don't want the complication of checking locales to see whether Babble is required, but it could easily be resolved within the library itself. Splitting translations into separate downloads by locale would allow users to get only what they need, giving us more control (at the cost of possible confusion for novice users). It just makes more sense design-wise, as it lightens the load on the user's computer quite a bit even if they use an EU client and switch between locales occasionally.
Of course, I could be missing something, in which case I'd very much like to know what it is...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAlso, by having a flat list of what spells (let's say) are available in English, you can check if a spell exists, which is very useful if you're dealing with situations where you don't necessarily know what's being fed in.