Thousands separator in rig control window does not respect current locale

[nsdecicco]

This is a minor bug that does not affect program usability.

In the current version of gpredict, the thousands separator in the rig control window is hard-coded to render as a decimal point (period). This is distracting for users of the software in locales where the separator should render as a comma.

I have opened a pull request (#272) which attempts to fix this issue by adding a gettext translation for this separator.

Another option I considered was exploiting the existing (system provided) translation of numeric output by sprintf(), by printing a numeric value (e.g., 1000) to a string, and extracting the separator from this, but this idea felt a little too hacky.

On my en_US machine, the rig control window now renders correctly:

[wkitty42]

On 11/7/21 4:19 PM, Nicholas DeCicco wrote:

I have opened a pull request (#272 https://github.com/csete/gpredict/pull/272) which attempts to fix this issue by adding a gettext translation for this separator.

one locale query at program start should gather the relevant data for formatting numbers, dates, and times to be used... then all these translation files do not need to be added or adjusted... this should be a quite normal and standard program initialization function...

this is a link to old documentation but it has enough relevance to provide the information i'm trying to convey... it was also the first valid result for the search query i used... https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_7.html

i understand windows has a different method of getting this same information... being able to determine which OS is being used and using the proper method should be quite easy...

[edit] added forgotten "windows" to the last paragraph above...

[nsdecicco]

Hi @wkitty42,

one locale query at program start should gather the relevant data for formatting numbers, dates, and times to be used [...] this is a link to old documentation but it has enough relevance to provide the information i'm trying to convey

Thanks for this link! I was trying to find something like this, but was having a hard time. I took a look at the glibc implementation of printf(), and this appeared to use the same gettext mechanism, which is odd considering that the approach that you've suggested is much simpler and more reliable.

I did find that the lconv struct and localeconv (which populates monetary and regular numeric entries of the lconv struct) is also present on Win32, so no change is needed for that platform. (Win32 does also provide an alternative to lconv in the form of GetLocaleInfo(A|W|Ex) in Winnls.h.)

Anyway, I went ahead and force-pushed a new commit (cca19a18) to the master branch of my fork (lasp/gpredict) that uses this mechanism instead.

Please take a look if you have a chance and let me know what you think.

Thanks,

Nick

[wkitty42]

i'm glad my comment was helpful! when i was doing more coding than i am now, i used to use this and similar methods all the time... it was trickier back then, though... especially in PASCAL whereas today's (Free)PASCAL is much easier in this respect... in any case, i'm glad my comment was helpful and put you onto a better track for this... hopefully similar can be used so that users can see the times and dates in their chosen locale formats (eg: i prefer YYYY/MM/DD even though i'm 'murican :smile_cat:)...

[csete]

Actually, this was intentional because the frequency display on communication equipment has always used . as separator and it seems to be that this convention is still followed today, including PC-based SDR applications. I am not sure why, perhaps because the display resolution is not always 1 Hz and the separator is both a thousands and a decimal separator, i.e. 145 MHz shown as 145.000.0

But I'm open to discussion whether we should change this to be grammatically correct or "do what everybody else does"

[csete]

The update has been merged.