Modified the ESX.IsValidLocaleString function to accept an optional `allowDigits` parameter.
When true, the function now allows numerical characters (0-9) in addition to the configured character ranges.
This improves string validation flexibility across locales.
- Replaced `ipairs` with a numeric `for` loop in the UTF-8 validation step for better performance.
- Stored `validRanges[i]` in a local `range` variable to avoid duplicate table lookups.
- Added a call to `ESX.ValidateType(str, 'string')` to ensure input is of type string before processing.
These changes improve both performance and code safety.
This update introduces a new configuration option `Config.ValidCharacterSets` to allow support for additional character sets in case the server is multilingual. This allows the server to handle character sets such as Greek, Cyrillic, Hebrew, Arabic, and East Asian languages (Chinese, Japanese, Korean).
By default, these character sets are disabled (`false`). The user can enable them if needed, depending on the language requirements of the server.
This commit introduces the new `ESX.IsValidLocaleString` function, which checks if a given string contains valid characters based on the configured locale. It validates characters from various locales, such as Greek, Cyrillic, Hebrew, Arabic, and Chinese, in addition to basic Latin characters. The function is flexible, allowing for the inclusion of additional character sets via the `Config.ValidCharacterSets` configuration.
Changes include:
- A new function, `ESX.IsValidLocaleString`, added to validate characters based on the locale.
- The validation takes into account default Latin ranges as well as specific ranges for supported languages.
- The function supports dynamic locale configurations by using `Config.ValidCharacterSets`.
This refactor improves handling of locale-specific characters and provides a way to easily extend validation for new locales as needed.
Replaced the manual character validation logic in checkNameFormat with ESX.IsValidLocaleString to centralize string validation and allow configuration of valid character sets per locale.
Added support for Config.ValidCharacterSets to enable or disable specific Unicode blocks such as Greek, Cyrillic, Hebrew, Arabic, or CJK (Chinese, Japanese, Korean). This change introduces greater flexibility for multilingual servers while maintaining basic Latin character support by default.
⚠️ Behavior changes: Characters that were previously allowed may now be rejected depending on the server’s locale configuration.
- Removed the redundant numeric check as it is already handled by the character validation.
- Simplified the name validation logic by keeping only the `checkValidCharacter()` function for validating characters.
- The `checkValidCharacter()` function checks for allowed characters: Latin, Greek, Cyrillic, Hebrew, Arabic, and CJK.
- Updated `checkNameFormat()` to rely solely on the new character validation logic.
Added a TriggerEvent when a job is created successfully, allowing developers to use an event listener and update ESX.Jobs, instead of importing the whole ESX object.
The queries assume that the parsed grades are numerically indexed. But removing ipairs method, and using pairs method, allows to loop grades that are indexed with strings as well. Just like we are using pairs method inside generatenewJobTable
Kenshin13