pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: making complex statements i18n friendly


From: Chusslove Illich
Subject: Re: making complex statements i18n friendly
Date: Sun, 4 Nov 2007 14:32:51 +0100
User-agent: KMail/1.9.7

> [: Ben Pfaff :]
> Here is one example. As you can see, it is attempting to ensure that a
> file cannot be opened for more than one purpose and, if this is attempted,
> give error messages that say exactly how the different purposes are being
> mixed: [...]

Here, given that you expect number of file types to change and that two-
combinations will grow very quickly, it is best to just leave it as it is,
and let translators handle it as they can. But, make sure to precisely
explain the sentence structure by a translator comment, say:

  /* TRANSLATORS: First argument is a file name, and the two others are file
     types. File type strings are translated separately below. */
  msg (SE, _("Can't read from %s as a %s because it is "
             "already being read as a %s.")

(comment starting with TRANSLATORS: just before the gettext call will get
automatically extracted by xgettext into template catalog.)

> Here is another example: [...] In this case there are 14 possible error
> messages, which is a bit many to write out explicitly. [...]

In this case I would advise that you write them out nevertheless. Unlike the
previous example, here you have a bounded set of states, and 14 messages in
total is really not that much.

Failing that -- for example if you also expect the number of states to
change -- it's better to at least go only one level of substitution, with
nice comments to translators:

  ...
  /* TRANSLATORS: This string is inserted into one of the
     "%s is allowed only..." messages below. */
  if (command->states & S_FILE_TYPE)
    allowed[allowed_cnt++] = _("inside FILE TYPE");
  ...
  if (allowed_cnt == 1)
    /* TRANSLATORS: First argument is a command name, and the second is
       one of the strings translated above. */
    s = xasprintf (_("%s is allowed only %s"), command->name, allowed[0]);
  else if (allowed_cnt == 2)
    /* TRANSLATORS: First argument is a command name, and the rest are
       one of the strings translated above. */
    s = xasprintf (_("%s is allowed only %s or %s"), command->name,
                   allowed[0], allowed[1]);
  else if (allowed_cnt == 3)
    /* TRANSLATORS: First argument is a command name, and the rest are
       one of the strings translated above. */
    s = xasprintf (_("%s is allowed only %s, %s or %s"), command->name,
                   allowed[0], allowed[1], allowed[2]);
  ...

> I would not mind suggestions for how to handle these specific cases, but
> more than that I am after general principles on how to handle these and
> similar cases. Ideas?

If there is a rather large and not really bounded set of inserts, then it's
best to just stick with proper English, and generously equip messages with
translator comments. That provides translators with enough context to
massage the strings into the least bad form for their language.

If the set of inserts is self-contained, not expected to change, and not
numerous (e.g. several dozen is never too much), then it's best to spell
them out.

In any case, more than one level of insertion when composing sentences
should be avoided whenever possible. It causes too much "dereference" to
translators, even if properly commented.

-- 
Chusslove Illich (Часлав Илић)

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]