[Aptitude-devel] Bug#738345: aptitude: [I18N] Use only original terms for command line options, arguments, etc. (do not accept translated terms)

[Manuel A. Fernandez Montecelo]

Package: aptitude
Version: 0.6.8.4-1
Priority: minor

This bug originates from #537858.  I am submitting a new one instead
of cloning because most of the issues have been resolved and the scope
of this specific part is much bigger (so most of the discussion in the
previous report is of no use).

The issue is that some strings, like "summary mode" for "why" command,
are marked for translation, and both original and translated forms are
accepted when given by the user.  This is not wrong per se, albeit a
bit inconsistent, because for example the "why" command itself does
not allow translation.

The issue is that the translators are confused sometimes about what
does need to translate and what not, or if they have to leave the
originals and translate at the same time, and in general creates some
overhead (for aptitude developers and translators), without much
benefit for the users.

This is also applied inconsistently, for example in src/main.cc the
translation of the log level is allowed (original term also accepted):

      // TRANSLATORS: This is a log level that the user can pass on
      // the command-line or set in the configuration file.
      add_level(N_("trace"), TRACE_LEVEL);

Same for the "why" command, as explained above:

  if(show_why_summary_mode == "no-summary" || show_why_summary_mode ==
_("no-summary"))
    why_display_mode = aptitude::why::no_summary;


But in src/generic/apt/matching/parse.cc, when parsing priorities,
dependency types and other things, only the original term is accepted.


In cmdline_versions.cc, it depends on the translators about what to do:

group_by_option parse_group_by_option(const std::string &option)
{
  // TRANSLATORS: if you add synonyms to the possible values here,
  // please also use the translations in your manpage and in the error
  // string below.
  if(option == "archive" ||
     option == P_("--group-by|archive"))
    return group_by_archive;
...


So according to my understanding with the discussion in #537858, it's
probably better to find all such occurrences and only allow the
original terms, deprecate the others with a warning, and then remove
the behaviour at some point in the future.

Translators then would always leave the original term and indicate
that it's the one to be given to the program, and translate for
explaining its meaning.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>