Quoting Chris Shoemaker <[EMAIL PROTECTED]>:

In that case why would you have the strings marked for translation?
I can't imagine you'd have a report that says (N_ "¿Donde esta el baño?")
if it's already translated and specific to a particular locale.  If all
the strings are pure strings then there's no harm in having that file
"marked" for translation.  The reverse, however, is an issue...

Ok, that's probably a poor example.

Heh..  Can you come up with a better example, then?

The thing is, the gettext programs really do expect that POTFILES.skip
may contain distributed files that aren't translated.  If we're sure
we don't want to use it for that then the reverse check is fine.

Well, then, perhaps that's not the filename we want to use...

I think we wouldn't want generated files to marked for translation,
even if they were distributed.  I don't know what we'd do if we wanted
to generate a .c file that didn't match our ignore patterns.

Why does it matter?  Do we expect generated files to have strings
that appear to be marked for translation but really aren't?

[snip]
I guess it boils down to "do we care about --maintain mode?"  If we
do, we should include the distributed, non-translated files in
POTFILES.skip.  If not, we might as well call it POTFILES.nodist and
check for accidental distribution.  In that case, we're not really
keeping a list of purposely non-translated files -- it's more a list
of files that _happen_ to be non-translated by virtue of not being
distributed.  Is that what we want?

I'm not sure we care about --maintain mode.  We certainly haven't ever
cared in the past.

So, yes, I think that what we want right now is a list of
files that happen to be non-translated by virtue of not being
distributed.

-chris

-derek
--
      Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
      Member, MIT Student Information Processing Board  (SIPB)
      URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
      [EMAIL PROTECTED]                        PGP key available


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to