-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Language, Localization Support #118
Comments
Thanks, @tonyyo11! |
I have a function in my SYM script at Pre-Flight after runAsUser that pretty much copies what erase-install.sh does. `setLocalizations() {
} setLocalizations` And then when passing the variable to the functions you just use the ! symbol:
I would share my complete script, but it's way too customized to be usable. Still, hopefully this provides an starting point. |
Are you going as far as setting the I feel like I'll have to have a massive Preflight section, while the rest of the actual core script is just localization variables. I think I can get that done. Just will take some time lol. |
@tonyyo11 I don't use a welcomeMessage, we pass department and other user-specific variables from LDAP/Jamf (https://macnotes.wordpress.com/2022/01/14/device-specific-parameters-for-jamf-pro-script-policies/) so the user doesn't have to input any data. |
I imagine you could grab the locale from the user, set your country code and then build case statements on your actual messaging accordingly, similar to: https://techitout.xyz/2023/04/12/setup-your-mac-zoom-room-edition/ |
@hooleahn your post above helped me start some of my customization, appreciate it as we're multi lingual. I can't seem to figure out how to pass a variable into the actual policy triggers so I'd also like to see multi language added into SYM maybe for V2 Editing in as to what I played with this morning was adding this into catch-all portion since I do not give prompts and I was able to have it select the JSON based on this - I haven't tested in pre-stage yet. ` ### #Detect the user's language
|
This line should be something like: |
Reviewed on |
Happy to assist with this! I was thinking of something as the following, variables and such can be changed around: # Set LOADED_LANG: This determines which language to load, prioritizing:
# 1. $USER_LANG (which can also be passed as $1) – the user’s selected language
# 2. LANG – the system-wide locale variables
# 3. "en_US" – the fallback default (English, United States) if no user or system language is set
LOADED_LANG=${USER_LANG:-${LANG:-en_US}}
# Function to load the appropriate language file if it exists
# $1 is the language code (e.g., "en_US", "fr")
# If the file is found, it loads the variables inside and returns success (0)
# If not, it returns failure (1)
load_lang() {
[ -f "./LANGUAGE/$1.lang" ] && source "./LANGUAGE/$1.lang" && echo "Loaded: $1" && return 0 || return 1;
}
# Try to load the language file for LOADED_LANG
load_lang "$LOADED_LANG"
Without LANG and shortened the code to make it tidier/easier to read: # Set LOADED_LANG: Use $USER_LANG (from input), or default to "en_US"
LOADED_LANG=${USER_LANG:-en_US}
# Function to load the appropriate language file using LOADED_LANG
# If the file is found, it sources the file and prints the file name, i.e. "Loaded: en_US"
# If not found, it prints "Language file not found"
load_lang() {
if [ -f "./LANGUAGE/$LOADED_LANG.lang" ]; then
source "./LANGUAGE/$LOADED_LANG.lang" && echo "Loaded: $LOADED_LANG"
else
echo "Language file not found: $LOADED_LANG"
fi
}
# Try to load the language file for LOADED_LANG
load_lang || load_lang "en-US" # <----- The second one could be from GitHub?
This would mean bringing all the text out of the code & placing in a secondary file. ** EDIT: Happy to remove "LC_ALL" as I'm not sure how well this would work. Maybe just a variable & a fallback option? |
Is your feature request related to a problem? Please describe.
Many organizations are multi-lingual and have to account for users who speak/read different languages. We are running into an issue where users with their systems set to fr-CA are forced to read SYM prompts written and designed for en-CA or en-US-based users.
Describe the solution you'd like
Although it could easily/potentially lead to "bloat", having code at the beginning of SYM to do a language check for localization would be extremely helpful. I'm not a coder, unfortunately, but I would imagine the SYM code would then have to wrap itself within an "en" array and have an option for admins to copy that section and paste it into multiple additional arrays for "fr" and "es". This would allow setting the headers, text, policy details, etc. into specified languages that admins would be required to translate to.
Describe alternatives you've considered
Presently looking into making a full copy of SYM and doing manual translation of all user-displayed text. Then scoping SYM-fr to a Smart Group within Jamf for French Speaking Users. My problem with that would be the requirement of a one-time inventory to Jamf prior to SYM starting off. Becomes even more troublesome when accounting for Prestage enrollments.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: