<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - EDITING: Regression in handling of the group separator in formula context" href="https://bugs.documentfoundation.org/show_bug.cgi?id=123752#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - EDITING: Regression in handling of the group separator in formula context" href="https://bugs.documentfoundation.org/show_bug.cgi?id=123752">bug 123752</a> from <a class="email" href="mailto:bugz.j@tukesoft.com" title="Jouni Kosonen <bugz.j@tukesoft.com>"> Jouni Kosonen</a> <pre>(In reply to Eike Rathke from <a href="show_bug.cgi?id=123752#c14">comment #14</a>) > The patch is wrong. It unconditionally adds the flag for every locale no > matter what parser flags the caller set and thus eliminates the purpose of > the flag. If at all then the flag should be set at caller level. But as > described earlier, doing so may also lead to unexpected behaviour if the > group separator equals the function parameter separator. This is a rather > twisted situation, and things interfere also with ScCompiler's lexical > analysis. Actually the i18npool parser is called only because the ScCompiler > parser decided it would not handle the character (left for investigation if > and how it could be solved at that level). Yes, but as I understand it there isn't a single line anywhere in the codebase that would set the flag – as things currently stand the group separator is unconditionally broken for all locales, some just don't show the symptoms. The ScCompiler parser may have decided it wouldn't handle the character but then the i18npool parser isn't allowed to recognize it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>