$(language).lua question

[Masteroshi430]

How does

Langs/en.lua
Langs/$(language).lua

(in the .txt file) work ?

I understood it charges the default en.lua language file and then the language file of the user language if any.
But let's say we have new variables in the en.lua file that are not in the fr.lua file, will these be displayed in english from the en.lua file charged before or will it cause an error/exception ?

[Shadowfen]

I understood it charges the default en.lua language file and then the language file of the user language if any. But let's say we have new variables in the en.lua file that are not in the fr.lua file, will these be displayed in english from the en.lua file charged before or will it cause an error/exception ?

By default, no. If you are displaying fr and the string is missing from fr then the value of the string will be nil even though there is an en value.

On the other hand, if you use LibLanguage, it was designed to load your default language first and then overload with the currently selected language so that (as in our example) the fr strings (when available) will be used and if not available then the default language (en in our example) would still be there.

[Scootworks]

Originally Posted by Shadowfen By default, no. If you are displaying fr and the string is missing from fr then the value of the string will be nil even though there is an en value. On the other hand, if you use LibLanguage, it was designed to load your default language first and then overload with the currently selected language so that (as in our example) the fr strings (when available) will be used and if not available then the default language (en in our example) would still be there.

that's not true... if you define this:

Langs/en.lua
Langs/$(language).lua

and use ZO_CreateStringId in en.lua and SafeAddString (for the other languages), the en string will be loaded as a fallback value. To answer your question, if the fr string is not available, the game will use the en string instead

[Baertram]

Scootworks is correct.

If you use the ZOs designed string constants way (create strings, update it with newer versions, read them via function GetString) of translation then the highest version of the string will be used. So if your lowest version is in en.lua and will be loaded, and no other language file overrrides the same language constant with the same or a higher version, the en version will be used.

https://wiki.esoui.com/How_to_add_localization_support


If you define your own string tables without that Zos feature it depends on your code what is used!
if you always override the same table, the last loaded one will be used. So if en.lua is always loaded and no other ylicnetlanguage.lua file is found it will be using en.lua then.
If another client file is found it will only use the table entries of this one.

Exception: You can use setmetatable and point the index of your fr.lua table to the en.lua table entries to "fill-up" missing fr.lua entries with the ones from en.lua as long as the table in en.lua is not already overridden in fr.lua!

[Shadowfen]

Sigh, LibLanguage is not creating it's own custom tables - it is performing the necessary, repetitive, boilerplate work of using ZO_CreateStringId and SafeAddString for you to ensure that the default language strings are loaded and then properly overridden with the new versions from the client language strings.

It's designed to be simple to use; simple to update; and simple for non-programmers to add new languages.

[Scootworks]

Nevertheless, there is already such an addon that follows a standard:
https://www.esoui.com/downloads/info...ibGetText.html

I assume LibLanguage is easy to handle too.

[Shadowfen]

Cool. Sad that it only came out 3 months after I wrote my own. I split it out into LibLanguage much later with the documentation of how to use it. Prior to that it was in LibSFUtils.

Had it existed before then, I would have checked it out.

[Baertram]

Okay, we should stop to discuss what came out when now. You act kind of hunted, so we need to stop this witch hunt now

I was not talking about your lib as I answered here but was providing info to the question, so not sure what the "sigh" relates to.
Scootworks neither was, he just pointed out that your first sentence of your first answer was not correct that way, so he provided more detail.

I guess all libs and technics mentioned are helping here and Masteroshi got his info now. Thanks to all of you