The 'updates' issue:
1.)
If someone is adding something new to the default language (and this is in all cases enUS) PLEASE, PLEASE add this changes (at the alphabetically same line) in ANY! locales with a comment (-- infront). Why? It is sooo much work to check the diff everytime (or the diff from more than one revision - and the diff from enUS and xyXY) after any update that is made to the default language.
The 'futurestuff' issue:
2.) Please do not add stuff (currently Ackis [sorry!] to Babble-Tradeskill-2.2) that is (may be...) in any future patch! If you want, add it with a comment (-- infront [and remember point 1.)]) and remove the comment when it goes live! (LIVE! not PTR!)... 2.4? hey that are weeks/months... EDIT: ok you are right, forget this...doesn't matter
And the shy hamster wanna know:(please: this one really needs some solution)
3.)
Babble-2.2 (Babble-Inventory-2.2, Babble-Spell-2.2 and Babble-Zone-2.2) has the same localized strings as
LibBabble-Inventory-3.0, LibBabble-Spell-3.0 and LibBabble-Zone-3.0.
Okay it has not, but ideally all should have the same. But, why has Babble* and LibBabble* not the same localized strings? Because someone has to maintain both versions. Doing point 1.) twice over and over again is horrible.
A simple solution could be: force authors to use one, freeze one, use one 'string'-file for both ...well I don't know... Anybody has some thoughts about this?
Sure, this is NO issue if you are using the enUS client...but if you are using deDE, esES, frFR, koKR, zhCN, zhTW, ruRU?! or whatever ... this is an issue!
Why I wrote this?
Because I want to know if this has been addressed in any way...
Because I want to know what the original author(s) of Babble* or LibBabble* (toc: ckknight [and in some way the whole Ace community]) think(s) about it...
Because I think we need some guides/rules for basic locales libs that are used in so many addons here!
And think about this one: Which one is better: Babble* or LibBabble*?
The simple answer is:
Not the one that is better coded. It's the one that is frequently maintained!
Babble, is really just a set of translation libraries that nobody maintains. They only get "maintained" when somebody (an addon author) feels like committing an extra spell or something to it, the absence of which would break the addon (of the same author) that uses it.
This is another of those libs that are in the strange zone of having multiple versions being used by different addons and no change in sight.
I would say it lies upon the ones that create a new lib version to anchor that decision before doing a new version. It should have support so other maintained addons using it get changed to use the new version and the old lib discontinued (in time).
Is there actually a nice way to use one of both? lol I mean, some addons I'd use demand LibBabble - others Babble.
Isn't Babble = Ace2, LibBabble = Rock?
I know there were a few other libraries that were like that... and it was the reason why I stayed with the older version. My mod = Ace2 and working under the assumption that if a person uses my add-on only, I didn't want them to have multiple frameworks clogging up the backend. Nothing against Rock. :)
no LibBabble is the new LibStubbed version that should be preferred over the old Babble-2.2 stuff. the problem is: there is not yet a LibStubbed version of some of the old libs.
You would never choose Babble-2.2 over LibBabble-Spell-3.0 (or any of the other babbles), because the latter has no external dependencies except the tiny LibStub that everyone uses now anyway. With that property a library can be used regardless of whether you choose to write your addon using Ace, Ace2, Ace3, Rock or Dongle or *any* other framework (or no framework). Babble-2.2 does not have this property and is deprecated because of that. The upgrade to LibBabble-Spell-3.0 is extremely straightforward, you just do:
local BS = LibStub("LibBabble-Spell-3.0"):GetLookupTable();
instead of:
local BS = AceLibrary("Babble-Spell-2.2")
If any translations are missing, you copy them over from Babble-2.2 and commit it to the Babble-3.0 one.
No Babble library was ever Rock. It is just that in order to get a library, say
local LBZ = LibStub("LibBabbleZone-3.0")
You can also get the exact same library by doing
local LBZ = Rock("LibBabbleZone-3.0")
local LBZ = LibStub:GetLibrary("LibBabbleZone-3.0")
local LBZ = AceLibrary("LibBabbleZone-3.0")
Note that you can even get a copy of each library thru each other's calls. That is
Rock("AceLibrary") will return AceLibrary. AceLibrary("LibRock-1.0") will return Rock. As will LibStub().
A simple solution could be: force authors to use one, freeze one, use one 'string'-file for both ...well I don't know... Anybody has some thoughts about this?
I would say use one 'string'-file for both, but... it would mean making an additionnal, "library-agnostic" file, where both Babble-* and LibBabble-* only have one file. And well, having one file would also mean using some kind of subversion external to embed it in each library, and I'm not sure that the files.wowace.com packager will play nicely with it...
Another solution could be some kind of nasty script to rip off strings from LibBabble-* and put it back into Babble-* file.
We updated alot of the mainstream addons today to use LibBabble-*-3.0 rather then the 2.2 versions.
I encourage all addon authors to update to the 3.0 versions if possible, so we can go back to using one translation library. :)
compat layers are ftl. I would rather see all addons update :)
A quick guide for updating: (using LibBabble-Spell-3.0 as an example here)
- Change the .toc/embeds.xml to point to LibBabble-Spell-3.0
(e.g. libs\LibBabble-Spell-3.0\lib.xml)
If the addon uses a embeds.xml approach, you need to change the <Script> tag to <Include>, for example
<Include file="libs\LibBabble-Spell-3.0\lib.xml" />
Also, do not forget to adjust the OptDeps and X-Embed
IMPORTANT: Always reference the lib.xml in your .toc/embeds.xml, and not the Babble Lua files directly!
- Change the Addons SVN Externals to point to LibBabble-Spell-3.0 instead of 2.2
- Update the AddOn itself
In most cases this is easy as exchanging the existing call
local BS = AceLibrary("Babble-Spell-2.2")
to the new
local BS = LibStub("LibBabble-Spell-3.0"):GetLookupTable()
However if your AddOn uses the :GetSpellIcon or Reverse tables, you need to change those calls too.
eg:
local LBS = LibStub("LibBabble-Spell-3.0")
local reverseBS = LBS:GetReverseLookupTable()
local icon = LBS:GetSpellIcon("Moonfire")
Some minor LibBabble* structure suggestions:
- separate files, one for each locale (ckknight did this in LibBabble-Spell r61661)
- all locales (incl. base enUS) should start at the same line number
This makes it easier to check diff between enUS/xyXY.
Some things I don't like:
The 'updates' issue:
1.)
If someone is adding something new to the default language (and this is in all cases enUS) PLEASE, PLEASE add this changes (at the alphabetically same line) in ANY! locales with a comment (-- infront). Why? It is sooo much work to check the diff everytime (or the diff from more than one revision - and the diff from enUS and xyXY) after any update that is made to the default language.
The 'futurestuff' issue:
2.) Please do not add stuff (currently Ackis [sorry!] to Babble-Tradeskill-2.2) that is (may be...) in any future patch! If you want, add it with a comment (-- infront [and remember point 1.)]) and remove the comment when it goes live! (LIVE! not PTR!)... 2.4? hey that are weeks/months...
EDIT: ok you are right, forget this...doesn't matter
And the shy hamster wanna know: (please: this one really needs some solution)
3.)
Babble-2.2 (Babble-Inventory-2.2, Babble-Spell-2.2 and Babble-Zone-2.2) has the same localized strings as
LibBabble-Inventory-3.0, LibBabble-Spell-3.0 and LibBabble-Zone-3.0.
Okay it has not, but ideally all should have the same. But, why has Babble* and LibBabble* not the same localized strings? Because someone has to maintain both versions. Doing point 1.) twice over and over again is horrible.
A simple solution could be: force authors to use one, freeze one, use one 'string'-file for both ...well I don't know... Anybody has some thoughts about this?
Sure, this is NO issue if you are using the enUS client...but if you are using deDE, esES, frFR, koKR, zhCN, zhTW, ruRU?! or whatever ... this is an issue!
Why I wrote this?
Because I want to know if this has been addressed in any way...
Because I want to know what the original author(s) of Babble* or LibBabble* (toc: ckknight [and in some way the whole Ace community]) think(s) about it...
Because I think we need some guides/rules for basic locales libs that are used in so many addons here!
And think about this one:
Which one is better: Babble* or LibBabble*?
The simple answer is:
Not the one that is better coded. It's the one that is frequently maintained!
regards, kunda
Regarding point 1, will do. You just want a -- before anything that gets modified so you know what has been changed?
Regarding point 2... does commenting out a few new zones/bosses on the PTR matter/not matter?
what?
okay you are right, this doesn't matter...
!
By "nobody maintains", I mean that nobody is in charge of it in particular. I know you do deDE translations a lot, keep it up kunda. :)
I would say it lies upon the ones that create a new lib version to anchor that decision before doing a new version. It should have support so other maintained addons using it get changed to use the new version and the old lib discontinued (in time).
Isn't Babble = Ace2, LibBabble = Rock?
I know there were a few other libraries that were like that... and it was the reason why I stayed with the older version. My mod = Ace2 and working under the assumption that if a person uses my add-on only, I didn't want them to have multiple frameworks clogging up the backend. Nothing against Rock. :)
local BS = LibStub("LibBabble-Spell-3.0"):GetLookupTable();
instead of:
local BS = AceLibrary("Babble-Spell-2.2")
If any translations are missing, you copy them over from Babble-2.2 and commit it to the Babble-3.0 one.
local LBZ = LibStub("LibBabbleZone-3.0")
You can also get the exact same library by doing
local LBZ = Rock("LibBabbleZone-3.0")
local LBZ = LibStub:GetLibrary("LibBabbleZone-3.0")
local LBZ = AceLibrary("LibBabbleZone-3.0")
Note that you can even get a copy of each library thru each other's calls. That is
Rock("AceLibrary") will return AceLibrary. AceLibrary("LibRock-1.0") will return Rock. As will LibStub().
I think it was Crayon, or could be associated with me not knowing what I was doing back then. I still don't, but I can pretend a bit better now.
I would say use one 'string'-file for both, but... it would mean making an additionnal, "library-agnostic" file, where both Babble-* and LibBabble-* only have one file. And well, having one file would also mean using some kind of subversion external to embed it in each library, and I'm not sure that the files.wowace.com packager will play nicely with it...
Another solution could be some kind of nasty script to rip off strings from LibBabble-* and put it back into Babble-* file.
We should make a group or something for "those who pretend to know what they are doing"
I encourage all addon authors to update to the 3.0 versions if possible, so we can go back to using one translation library. :)
A quick guide for updating: (using LibBabble-Spell-3.0 as an example here)
- Change the .toc/embeds.xml to point to LibBabble-Spell-3.0
(e.g. libs\LibBabble-Spell-3.0\lib.xml)
If the addon uses a embeds.xml approach, you need to change the <Script> tag to <Include>, for example
<Include file="libs\LibBabble-Spell-3.0\lib.xml" />
Also, do not forget to adjust the OptDeps and X-Embed
IMPORTANT: Always reference the lib.xml in your .toc/embeds.xml, and not the Babble Lua files directly!
- Change the Addons SVN Externals to point to LibBabble-Spell-3.0 instead of 2.2
- Update the AddOn itself
In most cases this is easy as exchanging the existing call
local BS = AceLibrary("Babble-Spell-2.2")
to the new
local BS = LibStub("LibBabble-Spell-3.0"):GetLookupTable()
However if your AddOn uses the :GetSpellIcon or Reverse tables, you need to change those calls too.
eg:
local LBS = LibStub("LibBabble-Spell-3.0")
local reverseBS = LBS:GetReverseLookupTable()
local icon = LBS:GetSpellIcon("Moonfire")
That would be nice.
Some minor LibBabble* structure suggestions:
- separate files, one for each locale (ckknight did this in LibBabble-Spell r61661)
- all locales (incl. base enUS) should start at the same line number
This makes it easier to check diff between enUS/xyXY.