AceLocale Question

Grimsin · 02-09-12, 05:30 PM

I noticed a lot of people have their locale files separated, I want to use one file for all languages is that possible with acelocale? Im trying the following and it says it cant find LdeDE...

Code:

-- US/English Localization enUS
local LenUS = LibStub("AceLocale-3.0"):NewLocale("GrimUI", "enUS", true, true)
--Binding Headers
LenUS["Raid Targeting Mouseover"] = true
LenUS["World Target / Flares"] = true
LenUS["Sound"] = true
LenUS["Temporary Mute"] = true
LenUS["Toggle Mute"] = true
LenUS["Blue Flare"] = true
LenUS["Green Flare"] = true
LenUS["Purple Flare"] = true
LenUS["Red Flare"] = true
LenUS["Yellow Flare"] = true
LenUS["Clear all World Targets"] = true

-- Germany/German Localization deDE
local LdeDE = LibStub("AceLocale-3.0"):NewLocale("GrimUI", "deDE")
--Binding Headers
LdeDE["Raid Targeting Mouseover"] = "Überfall Ziel Mausüber"
LdeDE["World Target / Flares"] = "Welt Ziel / Flare"
LdeDE["Sound"] = "Klingen"
LdeDE["Temporary Mute"] = "Temporäre Stummschaltung"
LdeDE["Toggle Mute"] = "Stummschaltung"
LdeDE["Blue Flare"] = "Blau Flare"
LdeDE["Green Flare"] = "Grüne Flare"
LdeDE["Purple Flare"] = "Lila Flare"
LdeDE["Red Flare"] = "Rot Flare"
LdeDE["Yellow Flare"] = "Gelb Flare"
LdeDE["Clear all World Targets"] = "Löschen aller Welt Ziele"

Phanx · 02-09-12, 05:34 PM

NewLocale only returns something if the locale is relevant to the user, so you need to check for that first:

Code:

-- Germany/German Localization deDE
local LdeDE = LibStub("AceLocale-3.0"):NewLocale("GrimUI", "deDE")
if LdeDE then
	--Binding Headers
	LdeDE["Raid Targeting Mouseover"] = "Überfall Ziel Mausüber"
	LdeDE["World Target / Flares"] = "Welt Ziel / Flare"
	LdeDE["Sound"] = "Klingen"
	LdeDE["Temporary Mute"] = "Temporäre Stummschaltung"
	LdeDE["Toggle Mute"] = "Stummschaltung"
	LdeDE["Blue Flare"] = "Blau Flare"
	LdeDE["Green Flare"] = "Grüne Flare"
	LdeDE["Purple Flare"] = "Lila Flare"
	LdeDE["Red Flare"] = "Rot Flare"
	LdeDE["Yellow Flare"] = "Gelb Flare"
	LdeDE["Clear all World Targets"] = "Löschen aller Welt Ziele"
end

I still don't know why you'd bother with AceLocale, though... it's just a waste of resources.

Grimsin · 02-09-12, 06:04 PM

What would you recomend Phanx? my own code for it? well for one because i just wanted to see if i could make it work right

my issue with doing it myself is im still working out in my head how locals are going to work with the LOD modules... like the settings which include the in game help and other modules as it becomes necessary. Also would like to get out of putting the ace register at the top of every one of my files that needs locale rather put it in my core and have it run anywhere... including my LOD's which brings me to another question so i noticed that i can make addon:function() work anywhere, i noticed that i could not do that in some of my lod modules. it would in others, namely the settings which Vrul setup... the top line has some things i dont understand i think that do it... i noticed that the _G[name] = addon are switched in certain spots... i know i asked about these lines in another post but i still dont understand what alls going on here lol. i have some funny business with my saved vars... some areas of the addon can find the variables after addon loaded check for GrimUI and some can not... why? anyhow what do these lines mean again? and here they are in all forms.

Core -

Code:

local addonName, addon = ...
_G[addonName] = addon

Every File including every file in LOD modules.

Code:

local addonName, addon = ...

In the core.lua inside GrimUI_Config folder which is an LOD addon.

Code:

local addonName, addon = ...
addonName = addonName:match("^(.+)_Config$")
addon = _G[addonName]
if not addon then return end

note - i do know what the last line does it checks for the addon right?

really need to know what that match bit is doing? is that what allows the use of addon: and GrimUI: between the lod config and the rest of the addon and vice verse? like if i put addon:func() in the LOD module with the top looking like the config file top does i can call the function from the other addon via addon:func() and both of them also work as GrimUI:func()

Phanx · 02-09-12, 06:13 PM

Localization.lua, load first in TOC:

Code:

local ADDON_NAME, addon = ...

local L = setmetatable({}, { __index = function(t, k)
	local v = tostring(k)
	rawset(t, k, v)
	return v
end })
addon.L = L

local LOCALE = GetLocale()

if LOCALE:match("^en") then
	-- No need to specify English translations
	-- since you are using the English text as
	-- the table key.
	-- Also no need to check other locales if
	-- this is an English client.
return end

-- German
if LOCALE == "deDE" then
	-- Binding Headers
	L["Raid Targeting Mouseover"] = "Überfall Ziel Mausüber"
	L["World Target / Flares"] = "Welt Ziel / Flare"
	L["Sound"] = "Klingen"
	L["Temporary Mute"] = "Temporäre Stummschaltung"
	L["Toggle Mute"] = "Stummschaltung"
	L["Blue Flare"] = "Blau Flare"
	L["Green Flare"] = "Grüne Flare"
	L["Purple Flare"] = "Lila Flare"
	L["Red Flare"] = "Rot Flare"
	L["Yellow Flare"] = "Gelb Flare"
	L["Clear all World Targets"] = "Löschen aller Welt Ziele"
return end

-- Spanish
if LOCALE == "esES" or LOCALE == "esMX" then
	-- Spanish translations here
end

-- other translations etc.

Other files:

Code:

local ADDON_NAME, addon = ...
local L = addon.L

blah:SetText(L["Blahblah"])

The heart of his method is 5 lines/105 bytes of code, vs 74 lines/2.25 kb for AceLocale (even after comments and blank lines are removed). Static memory is not critical, but why use 22x the code for the same end result with no meaningful benefits along the way?

Also:

You shouldn't need to check for the addon in LoD modules; just make sure the core addon is listed as a dependency in the module's TOC:

Code:

## LoadOnDemand: 1
## Dependencies: GrimUI

This will prevent the addon from ever being loaded if the GrimUI addon is not already loaded.

Grimsin · 02-09-12, 06:33 PM

if local L = addon.L wont i be able to use that accross the whole addon? or?

Phanx · 02-10-12, 02:12 AM

Why not? You already get a reference to the addon at the top of every file:

Code:

-- Example #1
local ADDON_NAME, addon = ...

So you simply get the L key from the addon table:

Code:

-- Example #2
local ADDON_NAME, addon = ...
local L = addon.L

Though if you didn't care about speed or efficiency, you could look it up in the addon table every time:

Code:

-- Example #3
local ADDON_NAME, addon = ...
blah:SetText(addon.L["Blah blah"])

And, if you put the addon table in the global namespace, as you did in one of your examples:

Code:

-- Example #4
local ADDON_NAME, addon = ...
_G[ADDON_NAME] = addon

Then the L table is also accessible from the global namespace, through the addon:

Code:

-- Example #5
print(_G[ADDON_NAME].L["Blah blah"])

If for some reason you really really wanted the L table to be in the global namespace separately, you could do that too, in the localization file, by adding:

Code:

-- Example #6
MyAddon_L = L

This would create a global variable "MyAddon_L" containing your L table.

Generally, however, you should avoid putting things into the global namespace separately. If you want your addon to be accessible from outside its own files (eg. by other addons) put one table into the global namespace, and add everything else to that table, as in examples 2–5. Example #6 is something you should get into the habit of not doing.

cokedrivers · 04-08-12, 11:38 AM

I have found a differnet way to choose a locale maybe its wrong or maybe its correct but it gets rid of alot of code.

Put this code at the top of your file.

Code:

local L = setmetatable({}, { __index = function(t,k)
    local v = tostring(k)
    rawset(t, k, v)
    return v
end })

Then (again not sure if this is correct) i just use the normal L['Hello'].

No need for L['Hello'] = true, in a seperate locale file.

Coke

Ketho · 04-08-12, 12:39 PM

This is what I use. It's slightly modified from Phanx' code

If say, there would be a non-existing/new locale (like itIT for Italian) then it would just fallback to enUS
If your locale is frFR but there is no existing table key (like frFR.HELLO_WORLD), then it will fallback to enUS (enUS.HELLO_WORLD), otherwise it will just return "HELLO_WORLD"

Locales.lua

Code:

local _, addon = ...

local L = {
	deDE = {
		HELLO_WORLD = "Hallo Welt!",
	},
	enUS = {
		HELLO_WORLD = "Hello World!",
	},
	esES = {
	},
	esMX = {
	},
	frFR = {
	},
	koKR = {
	},
	ptBR = {
	},
	ruRU = {
	},
	zhCN = {
	},
	zhTW = {
	},
}

addon.L = setmetatable(L[GetLocale()] or L.enUS, {__index = function(t, k)
	local v = rawget(L.enUS, k) or k
	rawset(t, k, v)
	return v
end})

MyAddon.lua

Code:

local _, addon = ...
local L = addon.L

print(L.HELLO_WORLD) -- prints your locale's key, otherwise prints "Hello World!"
print(L.SOMETHING) -- prints "SOMETHING"

Phanx · 04-08-12, 10:58 PM

Originally Posted by Ketho

This is what I use. It's slightly modified from Phanx' code

That works, though it appears to be more complicated and less efficient than mine. What advantages do you see in your code vs. my original code?

Originally Posted by cokedrivers

I have found a differnet way to choose a locale maybe its wrong or maybe its correct but it gets rid of alot of code.

Put this code at the top of your file.

Code:

local L = setmetatable({}, { __index = function(t,k)
    local v = tostring(k)
    rawset(t, k, v)
    return v
end })

Then (again not sure if this is correct) i just use the normal L['Hello'].

No need for L['Hello'] = true, in a seperate locale file.

That's exactly what I already posted... the only L["Hello"] = anything lines in my code are for non-English locales where "Hello" is not the correct word. What do you think is different?