<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 6, 2017 at 8:48 PM, John Emmas <span dir="ltr"><<a href="mailto:johne53@tiscali.co.uk" target="_blank">johne53@tiscali.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 05/01/2017 14:36, Robin Gareus wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some plugins expect to also *run* in the "C" or en_US locale.<br>
e.g. NI Kontakt fails in numeric-locales that use a comma, and<br>
NI isn't alone.<br>
<br>
<br>
If we add a custom system, I think it's better to<br>
<br>
  - don't change the locale at all, keep using the default "C" locale for<br>
C++/std::locale<br>
<br>
  - keep relying on standard functions for string-conversion<br>
<br>
and instead<br>
<br>
  - come up with a custom message-translation system that does not depend<br>
on the std::locale at the time the message is formatted.<br>
<br>
</blockquote>
<br></span>
Is this predominantly a Windows problem or do the other OS's also suffer from it?<br>
<br></blockquote><div><br></div><div>It is a problem that is relevent on any platform, If a plugin uses C/C++ library functions that are dependent on the global locale then numeric conversion will use the global locale setting for conversion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I only realised yesterday that on Windows, it seems to be possible for different threads (within the same application) to use different locale settings.  I haven't tested it in earnest but see the example at the bottom of this page:-<br>
<br>
<a href="https://msdn.microsoft.com/en-us/library/x99tb11d.aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-<wbr>us/library/x99tb11d.aspx</a><br>
<br>
Would that help at all?</blockquote><div><br></div><div>I mentioned in the original email that some platforms (well actually, only Windows that I know of) support per thread locale. It isn't helpful as the serialization/numeric conversion occurs in the GUI thread which needs the locale to be set/reset to the users preferred locale for localization anyway. If Ardour had been designed/implemented as some applications are to save/load state in a separate thread then it might be useful, but as it is platform specific and there are better solutions it isn't really of interest.</div><div><br></div><div>Tim</div></div></div></div>