Quantcast Game locale in toc - WoWInterface
Thread Tools Display Modes
05-29-13, 06:31 AM   #1
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
Game locale in toc

Give us an option to get the game's language in the toc file and load files based on that selection. Could speed up loading time a lot.
  Reply With Quote
05-29-13, 09:37 AM   #2
ravagernl
Proceritate Corporis
Premium Member
AddOn Author - Click to view addons
Join Date: Feb 2006
Posts: 1,176
You mean something like:
Code:
## Interface: 50300
[<rest of toc headers>]
init.lua
locales\locale.{locale}.lua
and the game should automatically replace {locale}? Or create a new toc header:
Code:
## Interface: 50300
## LoadForLocale: zhTW, zhCN
And then set OptionalDependencies in the actual addon toc to all of these locale addons.

Second option would seriously be spamming the AddOns folder, even tough AddOns like Bigwigs already do this, and I don't see Blizzard implementing option 1 at all.

Blizzard would rather implement interface/addon localization in XML (in a way that a table was inserted as the third argument to vararg ...) i think.

Last edited by ravagernl : 05-29-13 at 09:40 AM.
  Reply With Quote
05-29-13, 09:52 AM   #3
Dridzt
A Pyroguard Emberseer
 
Dridzt's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2005
Posts: 1,254
Or you could put all locales into one file so the game loads just the one....

(and use GetLocale() to process the relevant section)

Loading delays are caused in part by the game seeking to a file (sometimes not finding it and writing to FrameXML.log and so on)

If you use one file to keep all your locales that's not an issue.
  Reply With Quote
05-29-13, 10:20 AM   #4
Seerah
Fishing Trainer
 
Seerah's Avatar
WoWInterface Super Mod
Featured
Join Date: Oct 2006
Posts: 10,668
Or (if you really really want separate files per locale) you can put in a return at the top of the file. So, even if it loads the file, it won't compile the code unless it's the correct locale.

Lua Code:
  1. if GetLocale() ~= "enUS" then
  2.      return
  3. end
__________________
"You'd be surprised how many people violate this simple principle every day of their lives and try to fit square pegs into round holes, ignoring the clear reality that Things Are As They Are." -Benjamin Hoff, The Tao of Pooh

  Reply With Quote
05-29-13, 01:21 PM   #5
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
Originally Posted by Seerah View Post
Or (if you really really want separate files per locale) you can put in a return at the top of the file. So, even if it loads the file, it won't compile the code unless it's the correct locale.

Lua Code:
  1. if GetLocale() ~= "enUS" then
  2.      return
  3. end
Hmm i havn't tought about that, thats seems to be nice.
  Reply With Quote
05-29-13, 01:22 PM   #6
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
Originally Posted by Dridzt View Post
Or you could put all locales into one file so the game loads just the one....

(and use GetLocale() to process the relevant section)

Loading delays are caused in part by the game seeking to a file (sometimes not finding it and writing to FrameXML.log and so on)

If you use one file to keep all your locales that's not an issue.
Yeah, i curretly using this method, but still a lot of time seems to go to waste since you wont ever use most of them.
  Reply With Quote
05-29-13, 01:25 PM   #7
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
Originally Posted by ravagernl View Post
You mean something like:
Code:
## Interface: 50300
[<rest of toc headers>]
init.lua
locales\locale.{locale}.lua
and the game should automatically replace {locale}? Or create a new toc header:
Code:
## Interface: 50300
## LoadForLocale: zhTW, zhCN
And then set OptionalDependencies in the actual addon toc to all of these locale addons.

Second option would seriously be spamming the AddOns folder, even tough AddOns like Bigwigs already do this, and I don't see Blizzard implementing option 1 at all.

Blizzard would rather implement interface/addon localization in XML (in a way that a table was inserted as the third argument to vararg ...) i think.
Well i thing the best method would be like if you have more files for locales:

enUS.lua
enGB.lua

and you could load it from the toc like:

Code:
'gamelocale'.lua
Then you always load only one file, ignore the rest.
  Reply With Quote
06-24-15, 11:59 AM   #8
rowaasr13
A Fallenroot Satyr
AddOn Author - Click to view addons
Join Date: Jun 2007
Posts: 26
Originally Posted by Seerah View Post
Or (if you really really want separate files per locale) you can put in a return at the top of the file. So, even if it loads the file, it won't compile the code unless it's the correct locale.

Lua Code:
  1. if GetLocale() ~= "enUS" then
  2.      return
  3. end
Err... no. It certainly WILL compile entire file - chunks are always read and compiled completely and returned to reader and only THEN reader runs resulting code, performs check and bails out of it with return. So the only thing you're saving is object/function/closures instantiation and any run time that might be spent on any heavy loops if you have some bulk processing in your locale files.
  Reply With Quote
06-24-15, 03:05 PM   #9
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
It's kinda irrelevant now with SSD performances, however it's still kinda bugging me that 50% of your addon's memory usage are useless locale files thats for sure.

And yes the game loads those files into the memory too when you start the game, and i'm not sure they ever get collected to garbage or not.
  Reply With Quote
06-24-15, 03:17 PM   #10
Nimhfree
A Frostmaul Preserver
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 260
Originally Posted by Dridzt View Post
Or you could put all locales into one file so the game loads just the one....

(and use GetLocale() to process the relevant section)

Loading delays are caused in part by the game seeking to a file (sometimes not finding it and writing to FrameXML.log and so on)

If you use one file to keep all your locales that's not an issue.
Not for me. If you put all my different locale files into one file Blizzard cannot parse it as there is too much data. Therefore, I separate my files out by locale. I would love to have the option in the TOC to only load the locales that are actually being used.
  Reply With Quote
06-24-15, 04:16 PM   #11
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
I'm pretty sure it could be done tho, lets say in CurseClient/Minion you set the language you want to use your addons, then the client comments out every other language files from the toc or even don't even download those files, just like how the nolib strip works:

Toc Code:

It would not just speed up the download processes and save a fuckloads of traffic, but remove a lot of clutter and even slightly speed up the addon loading process.

Last edited by Resike : 06-24-15 at 04:18 PM.
  Reply With Quote
06-25-15, 02:49 AM   #12
rowaasr13
A Fallenroot Satyr
AddOn Author - Click to view addons
Join Date: Jun 2007
Posts: 26
Originally Posted by Resike View Post
It's kinda irrelevant now with SSD performances, however it's still kinda bugging me that 50% of your addon's memory usage are useless locale files thats for sure.

And yes the game loads those files into the memory too when you start the game, and i'm not sure they ever get collected to garbage or not.
If you use early returns the data is not even instantiated. Otherwise it all depends on how you programmed if you just build big table of all localization and never throw it away - it will stay in memory because, well, you put it here and didn't dispose it. Just don't do that.

There also source text and outer function bytecode itself - only Blizzard can tell if those are retained in memory after processing or not.
__________________
Garrison Mission Manager
  Reply With Quote
06-25-15, 07:05 AM   #13
Resike
A Pyroguard Emberseer
AddOn Author - Click to view addons
Join Date: Mar 2010
Posts: 1,289
Originally Posted by rowaasr13 View Post
If you use early returns the data is not even instantiated. Otherwise it all depends on how you programmed if you just build big table of all localization and never throw it away - it will stay in memory because, well, you put it here and didn't dispose it. Just don't do that.

There also source text and outer function bytecode itself - only Blizzard can tell if those are retained in memory after processing or not.
Try to login with the game with 5k "L" tables in every localization, then try to log in with only one set of tables, then compare the memory usage:

Lua Code:
  1. local AddonName, Addon = ...
  2.  
  3. local L = setmetatable({ }, {__index = function(t, k)
  4.     local v = tostring(k)
  5.     rawset(t, k, v)
  6.     return v
  7. end})
  8.  
  9. Addon.L = L
  10.  
  11. local locale = GetLocale()
  12.  
  13. if locale == "enUS" or locale == "enGB" then
  14.    
  15. elseif locale == "deDE" then
  16.    
  17. elseif locale == "esES" then
  18.    
  19. elseif locale == "esMX" then
  20.    
  21. elseif locale == "frFR" then
  22.    
  23. elseif locale == "itIT" then
  24.    
  25. elseif locale == "koKR" then
  26.    
  27. elseif locale == "ptBR" then
  28.    
  29. elseif locale == "ruRU" then
  30.    
  31. elseif locale == "zhCN" then
  32.    
  33. elseif locale == "zhTW" then
  34.    
  35. end

It doesn't really matter if your code doesn't run, if you put a file in the toc, then it will get loaded into the memory at least once per login/reload. My guess is that memory eventually will get garbaged, but it's still unnecessary loading time.

Last edited by Resike : 06-25-15 at 07:09 AM.
  Reply With Quote

WoWInterface » Developer Discussions » Wish List » Game locale in toc

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off