2. AceLocale-3.0 or a single locale file using if..elseif?
3. Anyone working on or is there a recent library for a menu system like DewDrop-2.0?
Thanks! :)
1) I'd keep it. Its easier for someone to blank out the entries in this file vs modifying your TOC.
2) I have used AceLocale, and my own function which returns locale tables with the following metatable:
[php]local loc_mt = {
__index = function(t, k)
_G.error("Locale key " .. tostring(k) .. " is not provided.")
end
}[/php]Re: XML, I like using it for exactly what people have mentioned - ecapsulating groups of files. XML also does one thing TOC can't, it allows you to specify paths *relative* to the xml file. I guess toc could too - but it is only allowed in one location.
I have found that after the first enumeration pass wow makes, most files are in the file cache - so the # of files doesn't have such a big impact. What you do in the main chunks of those files is the most important factor (for loading times). I have taken a liking to wrapping my main chunk in a closure and executing it later (preferably in a batch) so it isnt executing while its reading the file.
Normally wow does: read file, execute file, read file, execute file, and if lua is doing it, it normally has no concept of overlapped reads or anything like that. So keeping execution times small until after the read operations is ideal (i need to back this up with numbers sometime)
With WoWAce's new localization system, one doesn't have to depend as much on AceLocale3 as much as before, because a few adjustments:
-- Hard-code enUS/enGB.
local L = {
["Key"] = "Value",
}
do
local LOC = GetLocale()
if LOC == "deDE" then
-- Auto-injection.. etc..
elseif ...
end
end
Makes conversion simple. Anyone see any caveats with this method?
The only benefit I really see with using AceLocale is the ability to store the localizations in a separate file, which is my primary question. Does anyone have any creative ideas on how to do that? That is, storing the localization data in a single, separate file, without using AceLocale. I realize I could just create a temporary global var, but wanted to see if anyone had any other outside-the-box ideas. (Obviously, the localization file will have to be loaded first, so that nullifies using the addon object).
Edit: I realize that AceLocale is a small, simple library. And in most cases, if there's not that many phrases to be translated, then using it is silly and having a separate file is silly to begin with. I'm just trying to see what others think. :)
-- GatherMate Locale
-- Please use the Localization App on WoWAce to Update this
-- http://www.wowace.com/projects/gathermate/localization/ ;¶
local debug = false
--@debug@
debug = true
--@end-debug@
local L = LibStub("AceLocale-3.0"):NewLocale("GatherMate", "enUS", true, debug)
--@localization(locale="enUS", format="lua_additive_table", same-key-is-true=true, namespace="Options", table-name="L")@
local NL = LibStub("AceLocale-3.0"):NewLocale("GatherMateNodes", "enUS", true, debug)
--@localization(locale="enUS", format="lua_additive_table", same-key-is-true=true, namespace="Nodes", table-name="NL")@
deDE file:
-- GatherMate Locale
-- Please use the Localization App on WoWAce to Update this
-- http://www.wowace.com/projects/gathermate/localization/ ;¶
local L = LibStub("AceLocale-3.0"):NewLocale("GatherMate", "deDE")
if not L then return end
--@localization(locale="deDE", format="lua_additive_table", namespace="Options", table-name="L", handle-unlocalized="comment")@
local NL = LibStub("AceLocale-3.0"):NewLocale("GatherMateNodes", "deDE")
if not NL then return end
--@localization(locale="deDE", format="lua_additive_table", namespace="Nodes", table-name="NL", handle-unlocalized="comment")@
However, there is no real reason anymore for the locale files to be kept separately at all, since they are now auto-generated, and it no longer needs to be really human readable unless each locale's file is really huge (as in the case of GatherMate). Postal now does it in one file:
-- Postal Locale File
-- THIS CONTENTS OF THIS FILE IS AUTO-GENERATED BY THE WOWACE PACKAGER
-- Please use the Localization App on WoWAce to update this
-- at http://www.wowace.com/projects/postal/localization/
local AL3 = LibStub("AceLocale-3.0")
local debug = false
--@debug@
debug = true
--@end-debug@
local L = AL3:NewLocale("Postal", "enUS", true, debug)
if L then
--@localization(locale="enUS", format="lua_additive_table", same-key-is-true=true, table-name="L")@
[B]if GetLocale() == "enUS" or GetLocale() == "enGB" then return end[/B]
end
local L = AL3:NewLocale("Postal", "deDE")
if L then
--@localization(locale="deDE", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
local L = AL3:NewLocale("Postal", "esES") or AL3:NewLocale("Postal", "esMX")
if L then
--@localization(locale="esES", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
local L = AL3:NewLocale("Postal", "frFR")
if L then
--@localization(locale="frFR", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
local L = AL3:NewLocale("Postal", "koKR")
if L then
--@localization(locale="koKR", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
local L = AL3:NewLocale("Postal", "ruRU")
if L then
--@localization(locale="ruRU", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
local L = AL3:NewLocale("Postal", "zhCN")
if L then
--@localization(locale="zhCN", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
local L = AL3:NewLocale("Postal", "zhTW")
if L then
--@localization(locale="zhTW", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@
return
end
Note the use of if GetLocale() == "enUS" or GetLocale() == "enGB" then return end
which is different from other locales, because the base locale is always loaded (3rd argument is true indicates base locale).
The --@debug stuff produces a zip file that contains this:
local AL3 = LibStub("AceLocale-3.0")
local debug = false
--[===[@debug@
debug = true
--@end-debug@]===]
That is, the zipped file created by the packager comments out the debug sections. So if a user checkouts from the SVN, he gets the raw copy with debug=true, passed into the 4th arg, which makes AceLocale never error on reading non-existant keys.
Notice also the esES and esMX "hack" that is used, this is also employed by GatherMate:
[B]local L = LibStub("AceLocale-3.0"):NewLocale("GatherMate", "esES") or LibStub("AceLocale-3.0"):NewLocale("GatherMate", "esMX")[/B]
if not L then return end
That is, storing the localization data in a single, separate file, without using AceLocale. I realize I could just create a temporary global var, but wanted to see if anyone had any other outside-the-box ideas. (Obviously, the localization file will have to be loaded first, so that nullifies using the addon object).
Now of course, I realize that your question is about not using AceLocale,
In this case, you want something like this
-- Hard-code enUS/enGB.
local L = {
["Key"] = "Value",
}
do
local LOC = GetLocale()
if LOC == "deDE" then
[B]--@localization(locale="deDE", format="lua_additive_table", table-name="L", handle-unlocalized="comment")@[/B]
elseif ...
end
end
The substitution would then generate the overwriting
L["Key"] = "Translated Value"
stuff.
Actually, I'm using your "hacks" at the moment. What I was wondering was how to go about it in a single, separate file without using AceLocale. >.< As I mentioned, I realize AceLocale is small, but meh. Just trying to minimize the extras while keeping it organized.
P.S. Thanks for all your input and code, Xin. I can't begin to describe how much help you've been. :)
Edit: Bleh, you beat me to it. Right, that's what I was talking about doing, but I want to do it in a separate file. Damn OCD. >.<
enUS: Hardcode it, or use @localization(locale="enUS")@
MyAddOnLocale = {
["Key"] = "Blah"
}
deDE:
if GetLocale() == "deDE" then
--@localization(locale="deDE", format="lua_additive_table", table-name="[B]MyAddOnLocale[/B]", handle-unlocalized="comment")@
end
Main addon file:
local L = MyAddOnLocale
MyAddOnLocale = nil
Simply put, you need to use a global. Then nil it out in your main addon file if you are OCD about it.
1) I'd keep it. Its easier for someone to blank out the entries in this file vs modifying your TOC.
2) I have used AceLocale, and my own function which returns locale tables with the following metatable:
[php]local loc_mt = {
__index = function(t, k)
_G.error("Locale key " .. tostring(k) .. " is not provided.")
end
}[/php]Re: XML, I like using it for exactly what people have mentioned - ecapsulating groups of files. XML also does one thing TOC can't, it allows you to specify paths *relative* to the xml file. I guess toc could too - but it is only allowed in one location.
I have found that after the first enumeration pass wow makes, most files are in the file cache - so the # of files doesn't have such a big impact. What you do in the main chunks of those files is the most important factor (for loading times). I have taken a liking to wrapping my main chunk in a closure and executing it later (preferably in a batch) so it isnt executing while its reading the file.
Normally wow does: read file, execute file, read file, execute file, and if lua is doing it, it normally has no concept of overlapped reads or anything like that. So keeping execution times small until after the read operations is ideal (i need to back this up with numbers sometime)
With WoWAce's new localization system, one doesn't have to depend as much on AceLocale3 as much as before, because a few adjustments:
Makes conversion simple. Anyone see any caveats with this method?
The only benefit I really see with using AceLocale is the ability to store the localizations in a separate file, which is my primary question. Does anyone have any creative ideas on how to do that? That is, storing the localization data in a single, separate file, without using AceLocale. I realize I could just create a temporary global var, but wanted to see if anyone had any other outside-the-box ideas. (Obviously, the localization file will have to be loaded first, so that nullifies using the addon object).
Edit: I realize that AceLocale is a small, simple library. And in most cases, if there's not that many phrases to be translated, then using it is silly and having a separate file is silly to begin with. I'm just trying to see what others think. :)
enUS file:
deDE file:
However, there is no real reason anymore for the locale files to be kept separately at all, since they are now auto-generated, and it no longer needs to be really human readable unless each locale's file is really huge (as in the case of GatherMate). Postal now does it in one file:
Note the use of
if GetLocale() == "enUS" or GetLocale() == "enGB" then return end
which is different from other locales, because the base locale is always loaded (3rd argument is true indicates base locale).
The --@debug stuff produces a zip file that contains this:
That is, the zipped file created by the packager comments out the debug sections. So if a user checkouts from the SVN, he gets the raw copy with debug=true, passed into the 4th arg, which makes AceLocale never error on reading non-existant keys.
Notice also the esES and esMX "hack" that is used, this is also employed by GatherMate:
Now of course, I realize that your question is about not using AceLocale,
In this case, you want something like this
The substitution would then generate the overwriting
L["Key"] = "Translated Value"
stuff.
P.S. Thanks for all your input and code, Xin. I can't begin to describe how much help you've been. :)
Edit: Bleh, you beat me to it. Right, that's what I was talking about doing, but I want to do it in a separate file. Damn OCD. >.<
enUS: Hardcode it, or use @localization(locale="enUS")@
deDE:
Main addon file:
Simply put, you need to use a global. Then nil it out in your main addon file if you are OCD about it.
Ah. Thanks, AM. :)