NSF/NIH hates Europeans

Just kidding. But SciENcv hate browsers set to European locales.

Some users utilizing SciENcv to prepare documents may encounter an interesting bug: the input field for “Total Anticipated Amount” (Enter as USD) does not accept more than three digits. If typing value “12345”, the input text box will stuck at “123”; typing the 4th digit will make the input value goes back to “1” again. If copy-pasting a value “123456” into the input box, only “123” will show up. Pasting 7 or 8 digits will lead to only the first or second digits appearing in the box. So, I cannot type the correct amount into the box.

I always know the bug existed but never bother to find the root cause — it seems the bug goes away when I switch to a different browser. But why this input box behaved differently under different browsers? Thanks to the power of AI, nowadays we can simply decompile the minimized frontend JavaScript and found out what’s under-the-hood.

The reason? The webpage’s JS logic is trying to enforce some numerical formatting requirement, namely remove the commas and truncate after the dot, AFTER calling Number(value_str).toLocaleString(). In normal en-US locale, values like 123456 will be translated to "123,456" and converted back to the right value. Yet, if the browser is using some European locale like en-DE, the translated "123.456" will be considered a “non-integer” and truncated. Similarly, after typing 123, typing a 4 will lead to internal translation into "1.234", therefore truncating the value back into 1.

The toLocaleString translation logic will always be called, thus this user interface will never work for any browser with locale using dot as separator. I imagine some European scientists found this the hard way, while many others are still in the dark, not able to use the page properly to prepare the required forms. I hope more scientists (and their AI assistants) can found this article, so they won’t be stopped by this weird invisible barrier.

2025 年 09 月 05 日

AI, 前端

技术派