Editing Script Configs and Locales Without Breaking Anything

Almost every script you add to a FiveM or RedM server ships with a config file, and many ship with a folder of translations. These are the parts you are expected to change, and getting comfortable with them is the difference between a server that feels like yours and one that feels like a default install. This guide covers how config files and locale files usually work, and how to edit both safely.

What config.lua actually is

A config file is ordinary Lua that sets values the rest of the script reads. Most scripts create one table, often called Config, and fill it with settings such as prices, cooldowns, job names, blip colours and coordinates. Because it is real code, a single typo can stop the whole resource from starting. When a script fails right after you edit its config, the config is the first place to look.

Shared, client and server files

Open the resource's fxmanifest.lua and you will see which files load where. Files listed under shared_scripts or client_scripts are sent to every player's game. Files under server_scripts stay on the server. This matters for anything private: a Discord webhook URL, an API key or an admin list should never sit in a shared or client file, because players can read what they download. Well-made scripts keep these in a separate server-only config. If a script asks you to put a webhook in a shared config, consider moving it.

Common Lua mistakes in configs

• Missing commas between table entries. Every entry except the last needs one, and a trailing comma after the last one is allowed.
• Unclosed quotes or brackets, often caused by copying a value from a chat message that used curly "smart" quotes.
• Booleans in the wrong form. Lua uses lowercase true and false, with no quotes.
• Wrong coordinate type. Scripts often expect vector3(x, y, z) or vector4(x, y, z, heading). Passing three numbers where four are expected can place things facing the wrong way or break the script.
• Names that do not exist. Job names, item names and gang names must match exactly what your framework and inventory define, including capital letters.

How locale files work

Scripts that support several languages keep their player-facing text in locale files, usually in a locales folder with one file per language such as en.lua or en.json. The script refers to each line by a key, and the locale file maps that key to the actual text. The exact pattern depends on the framework or library:

• Many ESX scripts use a Locales['en'] table and look up text with _U('key'), with the active language chosen by a setting like Config.Locale.
• Many QBCore scripts build a Translations table and read it with Lang:t('section.key').
• Scripts built on ox_lib often store translations as JSON files and read them with locale('key').

Adding or editing a language

1. Copy the English file and rename the copy for your language, following the naming the script already uses.
2. Translate only the values. The keys on the left must stay exactly the same, or the script will not find the text.
3. Keep placeholders intact. ESX-style strings often use %s, while QBCore-style strings use named placeholders like {value}. Moving them inside the sentence is fine; deleting them is not.
4. Save the file as UTF-8 so accented characters display correctly.
5. Point the script at the new language using whatever setting its documentation describes, then restart the resource.

Surviving updates

The biggest config headache comes later, when a script updates. Keep a copy of your edited config and locale files outside the resource folder, and when a new version arrives, compare the old and new configs side by side before replacing anything. New versions often add settings, and copying your old file over the new one can silently remove them. This is much easier with open source FiveM scripts, where you can read exactly what changed. If you get stuck setting a resource up, the store's installation help page covers the basic steps.