GOption help output fails to convert UTF-8 ellipsis character correctly

Development
1

Commit 10c490cd introduced the UTF-8 ellipsis character for some reason. It does not get converted correctly to the C locale; it falls back to a question mark instead.

Reproducer:

#include <locale.h>
#include <stdio.h>

#include <glib.h>

int
main(int argc, char **argv)
{
  GOptionContext *context = g_option_context_new("Reproducer program");

  printf("Locale: %s\n", setlocale(LC_CTYPE, NULL));
  //printf("Locale: %s\n", setlocale(LC_CTYPE, "en_US.UTF-8"));

  g_option_context_parse(context, &argc, &argv, NULL);

  return 0;
}

With default (C) locale:

Locale: C
Usage:
  a.out [OPTION?] Reproducer program
...

With en_US.UTF-8 locale:

Locale: en_US.UTF-8
Usage:
  a.out [OPTION…] Reproducer program
...

Scott Hutton’s comment (linked below) pointed out similar undesirable behavior in 2018, but the issue was closed:

This might be covered by open issue g_convert / g_iconv support for transliteration (#117) · Issues · GNOME / GLib · GitLab , not entirely sure. I want to add another voice and give another example of the side effects that this change caused.

2

Call setlocale (LC_ALL, ""); near the start of main() to make sure your process is running in the user’s locale (as specified in their environment). Otherwise it will be running in the C locale, which only supports ASCII.

1 Like
3

Thanks! That’s a fine workaround. Ideally it would work in a reasonable way even with ASCII, but that can stay on the wishlist.

I thought our project’s code was already calling setlocale (LC_ALL, ""). But it turns out it does that immediately AFTER g_option_context_parse_strv(). So the help output uses the C locale. We can fix that on our end.

4

It’s not a workaround, it’s how you’re meant to set up the user’s locale with libc.

1 Like
5

Right, I’m not disagreeing with you. Your statement is objectively correct.

By “workaround,” I mean that IMO it’s desirable for messages to display correctly in an ASCII code set, when there is an reasonable way to do so. For example:

  1. There may be no reasonable drop-in replacement for Chinese or Cyrillic characters. If for some reason those appeared in the output, we’d probably have to fall back to '?’.
  2. Curly quote characters could be replaced by straight ASCII quotes.
  3. An ellipsis could be replaced by three dots.

*nix man pages and help outputs have used straight quotes and three-dot ellipses for years and it’s been fine. Implementation effort and time availability notwithstanding, IMO it would be nice for GLib to fall back to those representations if the code set is ASCII-only.

Anyway, setting the locale correctly should take care of this in the majority of environments. So thank you for pointing that out. I’ll address that on our end.

6

I’m not sure it is worth the effort to do character replacements like that. We’ve had Unicode for over 30 years now, and localised/internationalised interfaces are a pretty fundamental requirement of any publicly available software. Supporting ASCII-only environments is not something I see it worth putting resources into, given that upstream development resources are extremely limited.

1 Like