Adding a language

The locales/ folder is yours. Nothing in the resource holds a list of supported languages: fxmanifest.lua loads locales/*.lua as a glob, and a locale exists because a file wrote a table into Locales. Drop a file in, restart, it is there.

1. Copy locales/en.lua to locales/<code>.lua. Use whatever code you like — fr, de, pt-BR, sv. The file name is not read; only the table key is.

2. Change the table key on the first line: Locales["fr"] = {.

3. Translate the values. Leave the keys and any %s placeholders alone — a file with the wrong number of %s falls back to the unformatted string rather than taking the server down.

4. Set the language in section 1, GENERAL, of config.lua — the one setting there is for it:

   Config.Locale = "fr"

   Or leave it on "auto" and set it in server.cfg instead, if that is where your other resources take their language from:

   set nuggs:locale "fr"

   "auto" reads nuggs:locale, then esx:locale, then qb:locale, and stops at the first one that is set.

5. Restart and read the locales line in the startup banner. It names the language in use, where it was configured, and every language that loaded:

   locales        fr via config.lua - loaded: de, en, fr, pt-BR

   mcdiag reprints the same line at any time.

What the resource does for you

• locales/*.lua is in escrow_ignore and the manifest uses a glob, so a language you add is unencrypted, editable, and still there after an update. Updates only ever overwrite the files that ship with the resource.
• The code you configure does not have to match the file exactly. Case is ignored and - and _ are treated alike, so FR, fr, pt_BR and pt-br all find the right file. That matters most on "auto", where the code is whatever somebody typed into server.cfg months ago.
• "auto" works on the client too. A convar set with set rather than setr is invisible to clients, which would leave the server speaking the chosen language while the character screen every player looks at stayed English. The server replicates whatever it resolves under nuggs:locale, so both halves agree without you having to know any of that.
• A config with no Config.Locale in it still works. It is treated as "auto", so a config file written before this option existed keeps reading the convar it always read.
• A regional code falls back to its base language and back again. pt-BR finds locales/pt.lua if that is what the folder holds, and pt finds locales/pt-BR.lua if that is.
• A code with no file behind it is reported, once, in the console, with the list of languages that did load and what to copy. It does not fail silently into English.
• Missing keys fall back to English, key by key, on the Lua side and inside the interface alike — so a partial translation is safe to ship, and a translation written against an older build keeps working when an update adds a string. An empty string counts as a key nobody has reached yet and uses English too, so you can leave blanks in as you work.
• Keys are found in both halves of the file. Strings the interface renders live under UI, everything else at the top level, but a lookup checks both, so a key does not have to be in the half you would expect.

What is not translatable

The resource name lock’s messages. The folder this resource lives in must be named nuggs_multicharacter, and everything that says so is hard-coded in an encrypted file. A message whose only job is to tell a server owner how to fix their install has to survive a translation that dropped the key.

Sharing a translation

The file is plain Lua and depends on nothing else in the resource, so it can be handed to another server as-is. If you would like a language added to the shipped set, send the file in and it will go out with the next release under your name.

---