DYN-9801: Add Locale property to ExtensionStartupParams to pass locale info from Dynamo to apps like LibG#17060
Conversation
…m Dynamo to apps like LibG
There was a problem hiding this comment.
See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-9801
There was a problem hiding this comment.
Pull request overview
This PR extends the ExtensionStartupParams public API to carry locale information from Dynamo into FFI extension applications, and updates startup code paths to set UI culture earlier while removing the previous env-var–based locale plumbing.
Changes:
- Add a new
Localeproperty toAutodesk.DesignScript.Interfaces.ExtensionStartupParams(public API) and record it inPublicAPI.Unshipped.txt. - Pass the current UI culture name into extension apps via
ExtensionAppLoaderduringStartUp(...). - Simplify CLI/Sandbox/WPFCLI startup locale handling to only call
StartupUtils.SetLocale(...)(no longer capturing/using its return value).
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/NodeServices/PublicAPI.Unshipped.txt | Adds the new public API entries for ExtensionStartupParams.Locale get/set. |
| src/NodeServices/Interfaces.cs | Introduces ExtensionStartupParams.Locale on the public struct. |
| src/Engine/ProtoCore/FFI/ExtensionAppLoader.cs | Populates Locale when calling extensionApp.StartUp(...). |
| src/DynamoWPFCLI/Program.cs | Stops storing the SetLocale return value (now just calls it). |
| src/DynamoSandbox/DynamoCoreSetup.cs | Removes _putenv usage and only calls SetLocale. |
| src/DynamoCLI/Program.cs | Stops storing the SetLocale return value (now just calls it). |
| src/DynamoApplications/StartupUtils.cs | Changes SetLocale to only set UI culture (when provided) and return an empty string. |
zeusongit
left a comment
There was a problem hiding this comment.
LGTM, Selfserve passed here: https://c007.cloudbees-ci.autodesk.com/job/DYNCI/job/Dynamo/job/DynamoSelfServe/job/pullRequestValidation/108/
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|



Purpose
Part of DYN-9801. Companion Dynamo change for the LibG localization modernization in LibG PR #1648. This PR needs to be merged before LibG PR 1948.
Root cause of the old approach being broken
Dynamo previously set the LibG/gettext locale by calling
_putenv("LANGUAGE=xx_XX")via a P/Invoke tomsvcrt.dll. This was unreliable:msvcrt.dll's_environblock andlibintl.dll's own CRT_environblock are separate memory regions in the same process, so the write was never visible to gettext. In practice, geometry error strings were never reliably localized — gettext fell back to the Windows registry (Control Panel → Region), not to Dynamo's selected language.What LibG PR #1648 does
Replaces the env-var approach with a programmatic
Localization::set_language()C++ API (exposed to managed code via SWIG) that callslibintl_setlocale()directly intolibintl.dll's address space, bypassing the CRT boundary entirely. LibG'sIExtensionApplication.StartUp()now callsLocalization.initialize()andLocalization.set_language()using the locale passed in viaExtensionStartupParams.What this PR does
Localeproperty toExtensionStartupParams(NodeServices/Interfaces.cs) so Dynamo can pass the resolved UI locale toIExtensionApplicationimplementors like LibG.PublicAPI.Unshipped.txtfor theNodeServicesassembly.LocaleinExtensionAppLoader.InitializeExtensionApp()fromThread.CurrentThread.CurrentUICulture.Name(set earlier byDynamoModel.SetUICulture())._putenv("LANGUAGE=...")call and themsvcrt.dllP/Invoke fromDynamoCoreSetup— this never worked correctly (see root cause above).StartupUtils.SetLocale()and removed calls to it.Declarations
Check these if you believe they are true
Release Notes
N/A — internal localization plumbing change; no user-visible behavior changes in this PR alone. Geometry error string localization will work correctly once the companion LibG PR #1648 ships.
Reviewers
(FILL ME IN) Reviewer 1
This PR must be reviewed alongside LibG PR #1648 — both sides need to ship together. The key change reviewers should focus on is
ExtensionAppLoader.cs:Localeis read fromThread.CurrentThread.CurrentUICulture.Nameat the timeStartUp()is called, which is afterDynamoModel.SetUICulture()has run (locale is set during model construction; FFI assembly loading happens later on first graph execution).FYIs
(FILL ME IN, Optional) Names of anyone else you wish to be notified of