Status of i18n patches (again)

Status of i18n patches (again)

[Martin v. Loewis]

[Since the discussion quickly drifted off-topic without any answer to
my original question, I'll ask again:]

In GCC, translators of messages are faced with significant problems
when translating them. In many cases, messages are created by pasting
fragments of sentences. While this may work for English, it fails for
other languages.

A few months ago, Paolo Bonzini has created a patch that solves some
of these problems:

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01620.html

Can somebody please work with Paolo to apply this patch? 

If the patch is not acceptable in its current form, could someone
please give Paolo reasons for rejection?

If the patch needs to be split into several chunks, could somebody
please give Paolo directions on what parts of the patch can be more
readily integrated than others?

Thanks for your attention,
Martin

Re: Status of i18n patches (again)

[Geoff Keating]

martin@v.loewis.de (Martin v. Loewis) writes:

> http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01620.html

I looked at this patch, and have the following comments:

- The patch appears to do many different classes of things.  It should
  be broken up into one patch for each group of changes in the ChangeLog.
  Some can be approved very quickly.  The remainder will take longer.

- The patch creates a new source file containing only strings.  This
  seems out-of-place with the design of the i18n machinery, which is
  that strings exist in the source code, not out-of-line in some other
  file.  It might be better to:
  - Instead pass some other constant down to the diagnostic machinery,
    like the decl of the object in question or its TREE_CODE; or
  - Pass those strings down to the routine, for instance
    check_for_new_type (..., "within exception specifier"); or
  - Localise the combined string (that is, call gettext after calling
    sprintf), although you then have to work out how to tell xgettext
    what the possibilities are.
  As an indication of why this might be a good idea, this patch gets the
  check_for_new_type (..., "exception specifier");
  case wrong.

- Please consider writing testcases for any significant changes, if
  you can.

-- 
- Geoffrey Keating <geoffk@geoffk.org>