This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: an i18n sample



-          fprintf_unfiltered (gdb_stderr, "Type ");
+          fprintf_unfiltered (gdb_stderr, _("Type "));
          if (type == NULL)
-            fprintf_unfiltered (gdb_stderr, "(null)");
+            fprintf_unfiltered (gdb_stderr, _("(null)"));
          else
            type_print (type, "", gdb_stderr, -1);
-          error (" is not a structure or union type");
+          error (_(" is not a structure or union type"));


This fragment should be rewritten to use full sentences, like in
"Type (null) is not a structure or union type", instead of marking
each part separately.  That way, a translator will be able to
translate the entire sentence as a single entity, rather than each
part.  (Translating sentences in parts usually leads to bad
translations, unless the translator makes an effort to read the
source.)

This isn't the first time we've seen an attempt to mark up GDB. Last time, unfortunatly, things became bogged down by the desire to fix i18n code problems _before_ marking things, and that let to the process becomming stalled (it's scope became too large so nothing happened), and eventually dropped. Lets try to avoid that mistake this time.


Looking at the work, there are two tasks here:

- mark up gdb's strings
- fix i18n breakage

Where there's a trivial tweak, perhaps commit it, but for more complex cases we should consider leaving them(1), comming back later. We'll soon hear about it - the i18n users will soon alert us to where english is still showing through.

By doing this we can can limit the scope of the immediate task (so it can be completed), and then address the second over time.

Hmm, should we require all strings to be "marked-up", using a new macro ``I_()'' for identity strings - ones that shouldn't be translated. If we do that I can ARI this letting us catch new code not marked up.

Does that sound reasonable?

Andrew

PS: We could even mark the questionable cases up with D_() - deprecated - so that they are easier to find.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]