Re: [Po4a-dev] Status report of po-debconf

[Martin Quinson]

Hy there,

I'll try to keep my answer short.


On Tue, Aug 27, 2002 at 03:07:18PM +0200, Denis Barbier wrote:

>   5.  Po-debconf internals
>       --------------------
> 
> Following programs are shipped by po-debconf:
>   * debconf2po
>       Convert from native to po-debconf formats.  Performed only once.
>   * debconf2pot
>       Extract translatable text from _templates and writes templates.pot.
>       Wrapper to intltool-extract
>   * debconf2po-update
>       Update existing *.po files after generating a new templates.pot.
>       Wrapper to intltool-update
>   * po2debconf
>       Merge _templates and *.po files into templates.
>       Wrapper to intltool-merge
>   * dh_installpodebconf
>       Debhelper script to run po2debconf when building binary packages.
>   * TODO: po2debconf-revert
>       Convert from po-debconf to native formats.

Shouldn't this be called debconf2po-revert ? (or ever better,
debconf-ungettextize, see below)

> Before looking into these programs in depth, please note that
>   a.  For some intltool operations, a POTFILES.in file is mandatory.
>   b.  As other Debian files may later use a similar i18n scheme (e.g.
>       control file might be l10n'ed one day ;)), PO files are put in
>       a subdirectory arbitrarily named debian/po-templates/

Yup, I confirm, one day, dpkg's control file *will* be i18n'ed one day. See
the discution reappearing currently on debian-dpkg. I hope this time it wont
turn to a flamewar.

But I think that when it's done, it should be done using the po4a tools. So,
I'm not sure if we should split up po files here. I mean, why to do
debian/po-templates
debian/po-control
debian/po-???
[and by the way, debian/po-debconf is more clear that po-templates]
debian/po, with a "big" po both for control and template files per language
should be ok, don't you think so?

> debconf2po:
>   * Read templates files and generate po-templates/*.po
>   * TODO: improve handling of fuzzy entries, they are currently ignored
>     and should be marked as fuzzy
>   * Generate po-templates/POTFILES.in; this file must not be deleted
>   * Generate _templates
>   * When done, package maintainer must
>     a. edit _templates and check accuracy of marked entries
>     b. fix encoding specification within po-templates/*.po
>        (TODO: might be done automatically)

Or the translator may have to do that (like in xgettext).

>     c. delete old templates, templates.xx and templates.xx_XX files
>        Otherwise dh_installdebconf will process these files.

So, this tool is a gettextize for debconf templates, isn't it ? If yes, its
name should end with "ize", like libtoolize, gettextize, and some others.

[$ ls /usr/bin/*ize
gettextize  glib-gettextize  gvcolorize  imgsize  intltoolize  isosize
libtoolize  psresize  size  xml-i18n-toolize]

What about debconf-gettextize ?

> debconf2pot
>   * Read _templates and generate po-templates/templates.pot
> 
> debconf2po-update
>   * Read po-templates/POTFILES.in
>   * Parse files found in po-templates/POTFILES.in
>   * Generate po-templates/templates.pot
>   * Merge po-templates/templates.pot with existing po-templates/*.po

So, it's a wrapper to debconf2pot and msgmerge, isn't ?
 
> po2debconf
>   * Read po-templates/*.po files
>   * Merge _templates and up to date translations, output is sent
>     to stdout
> 
> dh_installpodebconf (run from top-level directory)
>   * If debian/_templates does not exist, do nothing
>   * run po2debconf with adequate arguments
>   * send output into package build directory
> 
>   6.  Roadmap
>       -------
> 
> Here is my current roadmap:
>   * Add patched intltool scripts until they are shipped by upstream
>   * Add regression tests
>   * Write documentation
>   * Debianize it and send an ITP

Why don't you want to get dh_installpodebconf integrated to dh_*, and other
wrapping tools added to debconf-utils ?
How do you plan to call this ?

>   7.  Discussion
>       ----------
> 
> All comments on this presentation are welcome.  There is another intereting
> topic we have to consider: do we want homogeneous behaviours?
> In other words, do we want to require that all our po2xx and xx2po scripts
> follow the same naming scheme and require the same command-line arguments?

I guess I would like to see a multi level interface here:
  - intltools direct interacction
  - xx-[un]gettextize, xx2pot, xxpo-update, po2xx sharing if possible the
    same arguments. Most of them are wrapper to intl corresponding tools,
    aren't they ?
  - dh_xx: I guess, most of the developer only want to use these ones.
  
  
To answer your question, yes, I'd like an homogeneous naming schem, and
command line arguments, when possible. 

Thanks for your work, I'm currently on a conference in Germany, so I have
pretty less time to look further at po4a at the moment, but I guess it'll go
better soon.

Bye, Mt.

-- 
Il ne faut pas confondre « La société m'opprime » et « le système m'étrique ».
          --- éphéméride du 19 juin