Opened 11 months ago

Last modified 8 weeks ago

#16312 new bug

HaikuDepot number formatting does not respect system settings

Reported by: bitigchi Owned by: apl-haiku
Priority: normal Milestone: Unscheduled
Component: Applications/HaikuDepot Version: R1/beta2
Keywords: i18n Cc:
Blocked By: Blocking:
Platform: All

Description

In Turkish, numbers are formatted as such: 1.234,56; , being the decimal separator. In HaikuDepot, download percentage indicator uses . for the decimal separator.

In addition, in Turkish % precedes the number, e.g., %56,5. HaikuDepot displays the % sign after the number as well.

I am not sure if this is 100% percent HaikuDepot bug, but have yet to observe this behaviour elsewhere.

Change History (9)

comment:1 by apl-haiku, 2 months ago

Looking in BFormattingConventions::GetNumericFormat, it doesn't look like the number formatting is implemented. Leave this open and hopefully it will be dealt with later.

comment:2 by pulkomandy, 2 months ago

You can use https://git.haiku-os.org/haiku/tree/headers/os/locale/NumberFormat.h to format numbers in the system selected locale.

comment:3 by apl-haiku, 2 months ago

Out of interest, in a couple of days, can you please try the nightly and see if it appears with the right formatting for the Turkish locale?

in reply to:  3 comment:4 by bitigchi, 2 months ago

Replying to apl-haiku:

Out of interest, in a couple of days, can you please try the nightly and see if it appears with the right formatting for the Turkish locale?

I tried hrev54982, and the percentage sign is correctly displayed preceding the number. Thank you very much! It looks like the only part left is the decimal separator.

comment:5 by apl-haiku, 2 months ago

It seems the ICU percentage formatting is not doing fractional percentages so I will leave it without the fractional part.

comment:6 by bitigchi, 2 months ago

Yes, that was also another thing I've noticed. Download progress was only incrementing by integers.

comment:7 by pulkomandy, 2 months ago

comment:8 by apl-haiku, 8 weeks ago

Hmmm... I am reading that the ICU NumberFormat instances are not thread safe [1] anyway so I guess it is safe to adjust the NumberFormat held by the BNumberFormatImpl on the fly.

[1] https://stackoverflow.com/questions/37521746/thread-safe-dynamic-pattern-for-numberformat-decimalformat

comment:9 by pulkomandy, 8 weeks ago

Yes, I had discussed thread safety issues when designing the API and the conclusion was that BeAPI things are usually not thread safe on their own, and it's up to application designers to avoid sharing objects between different threads, or set up their own locking.

In most cases you will be using objects inside a single looper so you are "automatically" safe. In cases where you do something else, you are on your own.

The exception to that is the global objects like BLocaleRoster default instance. In that case, the locale kit does its own locking and uses BMutableLocaleRoster to do the mutable parts (where BLocaleRoster doesn't allow any change to settings, so it has no thread safety problems).

Note: See TracTickets for help on using tickets.