bug-gettext
[Top][All Lists]
Advanced

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

Re: [bug-gettext] Bug#682580: xgettext: fails to properly replace some p


From: Francesco Poli
Subject: Re: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Date: Sun, 30 Aug 2015 11:46:57 +0200

On Thu, 27 Aug 2015 12:16:10 +0900 Daiki Ueno wrote:

> Francesco Poli <address@hidden> writes:
> 
> > I would definitely prefer to see xgettext changed, rather than having
> > to do sed or awk tricks to post-process its output.
> > So, to me, (4) is the least preferred option.
> 
> Sorry, I am not convinced.  Again, I am reluctant to add a new option to
> xgettext for a niche feature, without good reason.  Do you have any
> practical reason for that?

I thought the practical reason was clear: I want to automatically
generate a .pot template file from the program source, ready to be sent
to prospective translators.
xgettext seems to be a suitable tool to achieve this goal.
But the .pot template has to include the correct copyright notices,
assuming it indeed has to include any copyright notice.

Just having a .pot template file which says

  # Copyright (C) YEAR Python Software Foundation

when there are actually more copyright holders, is misleading and
confusing (and is vague with respect to the copyright years).

So, I am left with two options:

  • I post-process the .pot template generated by xgettext and insert
the correct copyright notices: this can be done by hand (boring and
error prone!) or automatically, for instance, with some sed or awk
trick (but then, why does xgettext have the --copyright-holder option
in the first place?!?)

  • I tell prospective translators to edit the fake copyright notice
and replace it with the correct copyright notices (boring for
translators and even more error prone!)


At this point I am really puzzled. The --copyright-holder option is
currently inadequate to make sure the .pot template file has the
correct copyright notices in place.

Hence, xgettext should have appropriate options to insert the correct
copyright notices.

Or, alternatively, it should drop the --copyright-holder option
entirely and produce a .pot file with

  # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER

replaced by

  # This file is copyrighted by the PACKAGE package's copyright holders
  # and by the translators listed below.

Of course, PACKAGE should be replaced by the argument of the
--package-name option, where available.

This way, we could do the following:

  $ xgettext --package-name=myapplication --package-version=0.1 \
             --language=python myapplication.py -o myapplication3.pot
  $ cat myapplication3.pot 
  # SOME DESCRIPTIVE TITLE.
  # This file is copyrighted by the myapplication package's copyright holders
  # and by the translators listed below.
  # This file is distributed under the same license as the myapplication 
package.
  # FIRST AUTHOR <address@hidden>, YEAR.
  #
  #, fuzzy
  msgid ""
  msgstr ""
  "Project-Id-Version: myapplication 0.1\n"
  "Report-Msgid-Bugs-To: \n"
  "POT-Creation-Date: 2012-07-23 22:49+0200\n"
  "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
  "Last-Translator: FULL NAME <address@hidden>\n"
  "Language-Team: LANGUAGE <address@hidden>\n"
  "Language: \n"
  "MIME-Version: 1.0\n"
  "Content-Type: text/plain; charset=CHARSET\n"
  "Content-Transfer-Encoding: 8bit\n"

  #: myapplication.py:6
  msgid "This is a translatable string."
  msgstr ""


> 
> My reasons for preferring (4) to (3) are:
[...]
> - that fits better in the Unix philosophy, which suggests to accomplish
>   larger tasks by combining small tools

As far as I understand the Unix design philosophy, there should be
small tools that do one thing (or, at most, a few things) and do it
well.
xgettext should generate a .pot template file and generate a good one.
In my own humble opinion, xgettext is currently failing at generating a
good .pot template file, as far as copyright notices are concerned.

I hope all this makes sense to you.
Please let me know, thanks for your time and patience!   :-)



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgpSFP8c2Dsf5.pgp
Description: PGP signature


reply via email to

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