[RFC] sanitize usage of gettext

[ghost]

Note: This is work in progress.

• What does this PR do?

Marking strings for translation isn't trivial. There are two common mistakes/antipatterns

1. Translating parts of a sentence and gluing the translation together:

   s1 = _("part 1");
   s2 = _("part 2");
   printf("%s %s", s1, s2);
   

   This should be

   printf(_("part 1 part 2");
   

   This antipattern is more common in its form

   printf(_("string with a %s placeholder"), b ? _("big") : _("small"));
   

2. Believing that plural is as simple as changing the word for its plural form

   if (i = 1)
      printf("one message");
   else
      printf("%d messages", i);
   

   In it's extreme form this is written as

   printf("%d message%s", i, i == 1 ? "", "s");
   

   However, other languages might have more than one plural form and seldom it is done by just appending a suffix (like s) to the noun. See the Polish example in the GNU gettext manual [0]

   The better way is to use ngettext(const char*, const char*, unsigned long int):

   printf(ngettext("one message", "%d messages", i), i);
   

This pull request/branch tries to fix some of the above stated mistakes. Also adding some comments and explanations for the translators where needed. (Also also one miss-usage of N_() instead of _() was fixed.)

The changes introduce a lot of new strings to be translated. I did my best to "reuse" the old translations for the new ones (using the seperate translations for singular/plural into one translation for ngettext, ...). As an end user you should get the same translation as before.

[0] https://www.gnu.org/software/gettext/manual/html_chapter/gettext.html#Plural-forms

• Are there points in the code the reviewer needs to double check?

Currently I've several questions:

• in signal.c:54
  There is different strings to translate depending on the OS:

  #if HAVE_DECL_SYS_SIGLIST
    printf(_("%s...  Exiting.\n"), sys_siglist[sig]);
  #elif (defined(__sun__) && defined(__svr4__))
    printf(_("Caught %s...  Exiting.\n"), _sys_siglist[sig]);
  #elif (defined(__alpha) && defined(__osf__))
    printf(_("Caught %s...  Exiting.\n"), __sys_siglist[sig]);
  #else
    printf(_("Caught signal %d...  Exiting.\n"), sig);
  #endif
  

  Does sys_siglist contain the Caught signal part on those OSes that miss it?

• commands.c:283
  I'd like to use ngettext() here. However, h is just a pointer and not the number of tagged messages.
  Is there an easy way to get the number of tagged messages? (cf in recvcmd.c the count_tagged() function).

[flatcap]

Wow, this is amazing. Thanks for the detailed explanation.

When I first started sorting out the translations, I read about ngettext().
It's very clever, but I don't remember ever finding any actual users of it :-)

I copied all the "Plural-Forms" settings from the Gnu translation site, so they should be correct.

Also also one mis-usage of N_() instead of _() was fixed

Well spotted.

in signal.c:54
There is different strings to translate depending on the OS:

I don't know, but as far as I can tell, the sig_list is just going to be a human-readable string. It's not a message we're going to see often, and when it does happen I'm not sure it's useful to translate the message...

NeoMutt just stopped with the message: "香蕉"

I think we should keep the sig_list name, but change the message to:

• Use one message for all OSs
• Include the signal number

Is there an easy way to get the number of tagged messages?

I don't think so. The places that use tagged messages tend to do an operation on one email, many times. Fortunately, in this case we can use the for loop above to count them. It's in an if (Context) clause, but I can't see how that could possibly be NULL. No Context, means no emails and no tagged emails.

There are probably more cases like this where we need to add a count parameter to functions.

[ghost]

Ready for review.

Besides some (more or less) trivial changes I needed to rewrite parts of the output routine for attachment headers (these [-- .... --] thingies). Please review them. They are located in handler.c in the functions external_body_handler() and mutt_body_handler().

There is also a small code snippet which counts messages (commands.c functions mutt_pipe_message(), mutt_print_message() and mutt_save_message_ctx()) which is new, so you might also have a look there.

I converted some of the more complex "gluing strings" to individual (complete) strings. Sometimes these "gluing strings" are format strings for a printf() call. Depending on how they are combined the resulting individual strings might have a different number of parameters. An example can be found in the function external_body_handler() in handler.c. To keep things simple (in the C code), I only called printf() once with the union of all parameters and used in those translatable strings which only need a subset of the parameters the syntax %2$s. When doing so, I added a comment for the translators that they are not surprised by this. I case you don't like this, I can change it at the cost of making the C code slightly more complex with a second printf() call (unless there is better solution).

In case you speak another language sufficiently fluent (no expert level needed), you can check the merged translations and remove the fuzzy flag if appropriate.

I think we should keep the sig_list name, but change the message to:

• Use one message for all OSs
• Include the signal number

I added the signal number to the string and adapted the translations by a simple search and replace approach: %d becomes %d (%s).

[flatcap]

Ready for review.

git diff master | wc -l
185221

I've spent a few hours looking over this.
I'll have some questions soon (hopefully).

[flatcap]

tl;dr
Very impressive. Merged. Thanks.

Discussion

(these [-- .... --] thingies). Please review them

I found one missing state_mark_attach(), but otherwise they are all good.

I, too, looked at removing the [-- and --] from the messages,
but realised that I'd need to printf() twice in some cases.
It would save the translator a little effort, but perhaps we'll leave that for now.

What I'm committing looks quite different to your branch, but it's not.
I've rearranged the commits so that the changes are smaller and simpler to understand.

Code changes

The first block are just the code changes.
I've made a few small tweaks here.

I've removed the *s from the L10N comment blocks.
When using a standard C block comment, the *s turn up in the .po file

You added L10N comments for the menu option strings:

/* L10N:
   These three letters correspond to the choices in the string:
   File exists, (o)verwrite, (a)ppend, or (c)ancel?
 */
switch (mutt_multi_choice(
    _("File exists, (o)verwrite, (a)ppend, or (c)ancel?"), _("oac")))

but unfortunately, they are placed next to the menu string because that comes first.
I've fixed this by inserting a comment into the mutt_multi_choice() arguments:

switch (mutt_multi_choice(
    _("File exists, (o)verwrite, (a)ppend, or (c)ancel?"),
    // L10N: Options for: File exists, (o)verwrite, (a)ppend, or (c)ancel?
    _("oac")))

Now the message will be associated with the options.

Update-po

This one enormous commit only updates the file references.
There are none of your magic changes here.

Magic Changes

Now that all the code changes have been made and all the references updated,
your magic changes to add plurals, etc, are actually quite small commits.
Their meaning is clear.