Oh okay, I didn’t know that there was a list thing behind ‘set up’. The list in two pictures, as the window can not be resized by dragging.
I just tested setting ‘grouping’ to ‘none’ instead of ‘space’ so it would type thousands as “1234” instead of “1 234” but if I type a space into Valentina, the error message appears immediately, and having set grouping to ‘none’, I still can’t type in four digit numbers.
Check Terminal > Preferences > Settings > [profile] > Advanced > Set locale environment variables on startup
If this is turned off, then the locale will default to “C” with no language specified, and most programs will then default to English!!! Maybe this is why your system returned Lang= with no value.
Check this to on, reboot your system, and try Valentina again.
Read more here: https://discussions.apple.com/thread/5481024?start=0&tstart=0
Set locale environment variables on startup is checked active.
LANG= LC_COLLATE=“C” LC_CTYPE=“UTF-8” LC_MESSAGES=“C” LC_MONETARY=“C” LC_NUMERIC=“C” LC_TIME=“C” LC_ALL= [/quote]
Wow, weird. We’ll have to look into why a Mac would have blank value for LANG and ‘C’ for location when clearly the language and region are selected. Your system lists your character encoding as UTF-8, so at least your keyboard settings are known. Perhaps something is overwriting them after startup.
Thanks for all this info.
I’ll have to look at this more tomorrow. I’m heading out for the evening.
I confirm the bug on Mac.
@d-old thanks. Did you manage to replicate it?
For now, I escape the bug by using a temporary workaround. If anyone else is having the same problem: * Say, I want to type in 1200 mm. I halve it, getting 600. * Into the function field in Valentina, I type in “600*2”
This results into the field displaying the correct 4-digit number. It’s a temporary fix that for now will allow me to get on with my project, but it’s still a bug and can get a bit unpractical in cases where Valentina automatically assumes calculations based on other measurements in the table. Let me know if you get further ideas on what I can test on my native Mac to help.
Okay, i try debug tomorrow.
I think i have found bug in C++ standard library on Mac. @slpencer, how do you think should i spend some time to submit a bug report? I plan to make my own implementation that will replace bugged place.
I think that it’s important to submit this bug report which includes a link to this thread. It seems that when a MAC OSX user has multiple locations AND multiple languages that OSX decides to stay neutral at the operating system level, such that it doesn’t set the language or location. Presumably each application checks the settings and import the language file and character set and use the math formatting rules that the user input into the settings dialogs, but the OS variables are not set, and the settings are cleared when the application closes.
Would this default behavior solve the problem: In cases where the OS returns blank values, Valentina defaults to language = US English (because this is usually 100% complete in Transifex), and location = US (because this matches the language setting and doesn’t require additional rules, uses decimals), and units = centimeter. I know most of our users aren’t in US, but this seems to be the simplest setting which will always default to a 100% complete translation.
As i said i believe this is bug in C++ standard library. I can repeat it on my Mac OS X. And bug related to std::locale class. Because if i don’t use locale or use C locale all work fine. But in our case we need locale with custom decimal point and thousand separators. And such combination fails. Today i will test my solution.
But still looks like we should try submit bug report for Clang developers.
Looking at this again, submitting a bug report wouldn’t be helpful. English language + Finland locale = en_FI, which isn’t defined by ICU. Libc++ doesn’t support custom combinations of locale and language for OS X, hence the weird results that @Riku experienced. Not sure that they will ever this implement this capability, as there are StackOverflow threads about this problem going back about 5 years. Here is the Boost thread on this issue: http://boost.2283326.n4.nabble.com/Locale-Getting-correct-system-locale-under-Mac-OS-X-td4654720.html
In Valentina OS X build, could we test if the lang/locale combo is in ICU CLDR? If the lang/locale combo doesn’t exist, then default to en_Latn_001 (English language, Latin script, World region) Here’s the formatting for en_Latn_001:
Decimal Pattern #,##0.### 1,234.56 Currency Pattern ¤#,##0.00 XXX1,234.56 Percent Pattern #,##0% 123,456% Scientific Pattern #E0 1.23456E3 NumberPatterns4 %%2d-year: 0: hundred; 1: oh-=%spellout-numbering=; 10: =%spellout-numbering=; … one thousand two hundred thirty-four point five six NumberPatterns5 %digits-ordinal: 0: =#,##0=(ordinal,one{st}two{nd}few{rd}other{th}); -x: −>%… 1,235th NumberPatterns6 %with-words: 0: 0 seconds; 1: 1 second; 2: =#0= seconds; 60/60: <%%min<; 61/60:… 21:35 NumberPatterns9 ¤¤#,##0.00 ¤¤1,234.56 NumberPatterns10 #,##0.### ¤¤¤ 1,234.56 ¤¤¤ NumberPatterns11 ¤#,##0.00;(¤#,##0.00) ¤1,234.56 NumberPatterns12 ¤#,##0.00 ¤1,234.56 NumberPatterns13 @## 1.23K NumberPatterns14 @## 1.23 thousand NumberPatterns15 ¤#,##0.00 ¤1,234.56
@slpencer, i have feeling you did not try mac port. I can repeat the problem without weird combination. And debugging showed that the problem is not related to such combination. The combination is absolutely different. C locale + custom decimal point and custom thousand separator. When i use just C locale or none all work.
Originally muparser library always use C locale. I did not set something different.
This bug showed bigger problem with support locales. We use muparser in different way. It also parse user input in user locale. And this is the reason why i so long fix this bug. I have found that we have at least three negative signs and 7 digit variations for each digit! And we should support them all to be able to parse user input.
Here is page with all unicode digit. Qt supports only 7 different, but there is even more.
Okay, you found a separate bug and the known problems with Mac OS X’s localization are not involved in this particular issue. Even so, for future reference it’s good to be aware of the known localization issues in Mac OS X, because the symptoms of the two issues greatly overlap.
Valentina will not have this issue. I made a solution that resolve the problem. It is big and should very good tested, but will work.
Okay let us know when the fix is merged and I will coordinate international testing.
Don’t worry, i hope my unit tests will cover 99.9% of all cases.
Opened new ticket for this issue [#606] Mac OS X. Can’t type in measurements due to digit count limitation.
Fix released. Finally. 
A patch for branch 0.4.x has been released.
This thread will be closed, if you still see this bug please reopen issue [#606] Mac OS X. Can’t type in measurements due to digit count limitation.