Closed lw-schick closed 7 years ago
Thank for you the suggestion. Our engineers have been looking into your approach, but we ran into some issues.
By changing the culture of the Thread in the class initialization, it also appeared to be impacting the culture of the user application program as well as the SDK which led to unintended side effects.
Also, we observed differences in the operation depending upon the order in which the Client was initialized in the user's program (if the user was changing the Thread culture in their application after the Client was initialized). While your solution appeared to be more elegant (less lines of code) than pull request #10, it appears that #10 might be more robust (we are still testing it).
I'll leave this pull request open for now pending the outcome of our testing with #10.
The feature was implemented in an alternate way.
This is an alternative solution for #5 issue: On initialization of a
Client
object the default culture for the assembly Thread is set toen-US
(see also)That's not a nice way of doing it - it would be better to fix all culture individual methods to CultureInfo.InvariantCulture. Or alternatively set the whole assembly culture to
en-US
. But unfortunately, it seems that there is no way of doing that via a[assembly: ...]
attribute.