Bug #13776
Updated by Jim Pingle over 1 year ago
Some languages are defined in the pfSense translations system without a location, such as French which is defined as "fr". The problem is that certain functions expect to be able to load a locale using the same name. However, there are not always matches for these exactly as we specify them. The easiest one to check if it works or not is *Diagnostics > System Activity* (@diag_system_activity.php@) or run @top@ from *Diagnostics > Command Prompt* (@diag_command.php@). Looking in @/usr/share/locale@ on a dev snapshot there are several variations of French: <pre> /usr/share/locale/fr_BE.UTF-8 /usr/share/locale/fr_CA.UTF-8 /usr/share/locale/fr_CH.UTF-8 /usr/share/locale/fr_FR.UTF-8 </pre> We should likely be setting the language as "fr_FR" in this case for example. Languages we specify fully matching, such as en_US or pt_BR work as-is. Some we have a location on but it doesn't match a locale (e.g. some of the variations of Chinese) and those maybe harder to fix. Chinese). Languages we specify fully matching, such as en_US or pt_BR work as-is. So we either need to change the language names in the backend to match equivalent locale definitions or separately set the lang and locale to appropriate values. If we change the names in the backend we will need upgrade code to ensure the user is moved to the new name on upgrade.